from:"A Verhees"


These are all very good reasons.

So I make an ADL serializer, so I can always represent my archetype ADL 
for archive purpose.
But the complexity of the parser, that I don't want anymore. Life is 
short. And there are better things to do.


As said, I am building an BMM/AOM environment as a hobby project, just 
for fun. I don't know where I will end up. But one of my important goals 
is to avoid complexity.

We'll see where it goes too.

I started this discussion yesterday with the question if there are 
technical objections to represent archetypes in JSON. I was not sure 
that I was overseeing it all.
Now I am, and I understand that there are no technical objections, so 
that makes me glad.


have a nice day
Bert

On 16-02-19 15:10, Thomas Beale wrote:



On 16/02/2019 14:00, Bert Verhees wrote:

On 16-02-19 13:20, Thomas Beale wrote:


Have a look at the Archie project 
<https://github.com/openEHR/archie>, you'll find very vanilla Java 
facilities used to do most of this work.


Thank you for pointing this out. But I already knew this. My point is 
not that it is easy to dump an ADL archetype via a parser to a JSON 
representation. My point is that the JSON representation must be the 
result and working modus of archetype/data-handling, in the 
archetype-designer and in the repositories. So the ADL parser and all 
that complex code around it becomes superfluous. There should be no 
temptation to do any processing with ADL.


Even in tools that read ADL archetypes, hardly any of the processing 
is done in ADL, it is done on the in-memory AOM structure - that's 
true both in Archetype modelling tools and runtime validation tools.


The utility of ADL as a syntax, apart from being human-readable (at 
least for those who understand the semantic basis of archetypes) is 
that it never changes, whereas object syntaxes, XML etc are changing 
all the time. This month we are using this flavour of JSON, next month 
it is another flavour. Next year, everyone decides they like YAML 
instead. IT is mostly a fashion show of these kinds of changes.


It's the same with programming languages - their syntax changes only 
with the semantic changes (e.g. Java 1.5 -> 1.8), but not with 
compiled representation.


So I am all for using JSON or whatever in the way that you say, but we 
should just remember that such syntaxes are machine formats optimised 
for something, and they will always be replaced by another format(s) 
optimised for something else. Saving out to ADL can be very useful 
sometimes, in case you want to guarantee to preserve semantics across 
these changes.


The other reason ADL exists is that it is a lot easier for humans to 
learn the archetype formalism via the ADL specification than the AOM 
specification, even though the latter is the one containing most of 
the formal semantics.


- thomas



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



--
*Bert Verhees*
Software developer, architect

Profile: https://www.bertverhees.nl/

Twitter: https://twitter.com/VerheesBert
LinkedIn: https://www.linkedin.com/in/bertverhees/
Email: bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>
Mobile: +31 06 28050294
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: FW: Re: JSON for definitions-notation


On 16-02-19 13:20, Thomas Beale wrote:



On 16/02/2019 01:38, Bert Verhees wrote:


A few last words on this.

It is easy for JSON based archetype repository to cooperate with an 
ADL based repository. Serializing of an AOM structure to ADL is very 
easy to do, this counts for the DADL and CADL part. The other way 
around, to convert the ADL definition part to JSON is harder, that 
involves the parser-code and grammars which are hard to maintain.


Actually, the AOM -> JSON serialiser is generic code - in my Eiffel 
code base, it is a generic converter from in-memory objects (AOM 
instances) to something like a DOM tree (another in-memory structure 
consisting of just a few types of node and leaf objects) which is then 
trivially serialised to JSON, ODIN and YAML.


More modern libraries as found in Java and all other mainstream 
languages these days do the same, and additionally streaming parser 
tools that can potentially make the conversion quicker (in bulk).


Have a look at the Archie project <https://github.com/openEHR/archie>, 
you'll find very vanilla Java facilities used to do most of this work.


Thank you for pointing this out. But I already knew this. My point is 
not that it is easy to dump an ADL archetype via a parser to a JSON 
representation. My point is that the JSON representation must be the 
result and working modus of archetype/data-handling, in the 
archetype-designer and in the repositories. So the ADL parser and all 
that complex code around it becomes superfluous. There should be no 
temptation to do any processing with ADL.


If there is desire to have ADL-files, it is easy to serialize to them, 
as you already indicated.


And yes, there is YAML too, and ODIN, but both have as disadvantage that 
there is less support in industry then there is for JSON. So libraries 
to do fancy things with JSON are many. I also do not see why JSON would 
be a bad choice, so there is no reason for looking further then that.


Bert



- thomas


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



--
*Bert Verhees*
Software developer, architect

Profile: https://www.bertverhees.nl/

Twitter: https://twitter.com/VerheesBert
LinkedIn: https://www.linkedin.com/in/bertverhees/
Email: bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>
Mobile: +31 06 28050294
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: FW: Re: JSON for definitions-notation


On 16-02-19 13:16, Thomas Beale wrote:

Bert,

if you serialise a AOM archetype to any object dump format, you need 
typing information for the simple reason that there is polymorphism in 
the model, mainly places where the static type is C_OBJECT, 
C_DEFINED_OBJECT or C_PRIMITIVE_OBJECT but the attached type in a real 
archetype can be a number of descendant types.


W.r.t. the naming convention of RM types, attributes etc, I assume you 
are referring to the fact that openEHR archetypes use the published RM 
type and attribute name format, which is so-called 'snake-case' rather 
than 'camelCase'. To make archetypes that refer to data objects usable 
across software written in different languages using different case 
conventions, it may make sense to add an option to OPT generation 
which indicates the flavour of RM casing. I had not thought of this 
before but it would be easy to implement in an OPT generator.


BMM is getting more powerful by the way. I have recently extended it 
so that it allows types to be annotated with a 'value-set' identifier, 
which can be used to limit the values of e.g. data fields of type 
CodePhrase or TerminologyCode to particular terminologies. \



I understand that you need type information to make an archetype 
understandable for humans, but you don't need it for validating 
datasets, because in validating only the in the archetype defined 
properties/constraints are important and the JSON or XML datasets also 
do not have type-information. The constraint in the leaf-node indicates 
which type the leaf-node is of. So type-information is unnecessary load 
in the validation-part (definition) of an archetype.


Here you see a JSON and an XML having the same information. No explicit 
type information is in it.


{
"glossary": {
"title": "example glossary",
"GlossDiv": {
"title": "S",
"GlossList": {
"GlossEntry": {
"ID": "SGML",
"SortAs": "SGML",
"GlossTerm": "Standard Generalized Markup 
Language",
"Acronym": "SGML",
"Abbrev": "ISO 8879:1986",
"GlossDef": {
"para": "A meta-markup language, used to create markup 
languages such as DocBook.",
"GlossSeeAlso": ["GML", "XML"]
},
"GlossSee": "markup"
}
}
}
}
}

 example glossary
  S
   

 Standard Generalized Markup Language
 SGML
 ISO 8879:1986
 
  A meta-markup language, used to create markup
languages such as DocBook.
  
  
 
 

   
  
 

But for humans, it must be available to understand an archetype, that is 
the semantic part, and must be taken care of. For that problem are 
several solutions. There can be a documentation-file, separate, or 
included, another solution is that the ontology can be extended with 
"type", next to "text" and "description", and maybe more ontology items. 
I think I favor an ontology-based solution.


Important for the JSON solution to work is that the JSON must not 
reflect beyond the extend of the classes, there may not be something in 
the JSON, which is not in the classes, because in that case, you might 
lose the advantages which are in JSON when flattening or creating 
templates, which can be done just by filling up AOM-object properties 
with objects from other archetypes and then serialize again for 
validation purpose.


I have not thought all through, but I think that there will be very many 
advantages in handling AOM objects/JSON instead of fiddling around with 
paths and finding ways to find the type of a path-node.


Regarding the naming conventions is always discussion. In ISO13606 
properties have two different name-conventions for properties, 
snake-case and camelCase, and that in one standard, even in one class. 
In DATA_VALUE there is "nullFlavor" and in URI which descents from 
DATA_VALUE, there is "fragment_id". But then again, it is up to the 
reference-model designer. Some property-names came from HL7 and the 
desire to be in line with HL7 regarding properties with the same name 
made them keeping the same property-name-convention.


So the tooling and definition for reference-model-design must be 
agnostic to this.


Regarding your third line, I don know if I understand well, but for me 
it is best when BMM is domain-neutral, and bringing in 
terminology-information could harm this idea, except for when it is made 
completely voluntary to use. But I don't know why it should be there, 
and I don't see it as powerful. Sometimes, less is more.


Bert


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

Re: FW: Re: JSON for definitions-notation

Thanks very much for your reply. I did find a link on this which help to study 
this more. 

https://stackoverflow.com/questions/13502398/json-integers-limit-on-size/39681707#39681707

Of course this is not a problem on archetypes but on datasets it can be. 

Also worth considering is that there are more kinds of JSON like for example 
GeoJSON. And there is JSON for expressing mathematical operations. Useful for 
storing mathematical procedures in a database. 

Best regards
Bert 


Sent from my Xperia™ by Sony smartphone

 William Archibald wrote 

>I agree with you, except for how damn limiting pure json* is. Any attempt
>to introduce long-ints or annotation take you to vertical-specific json+.
>
>
>* json is javascript, so has type and other limitations.
>
>On Fri, Feb 15, 2019, 7:39 PM Bert Verhees 
>> A few last words on this.
>>
>> It is easy for JSON based archetype repository to cooperate with an ADL
>> based repository. Serializing of an AOM structure to ADL is very easy to
>> do, this counts for the DADL and CADL part. The other way around, to
>> convert the ADL definition part to JSON is harder, that involves the
>> parser-code and grammars which are hard to maintain.
>>
>> It is fragile code.
>>
>> I remember how hard it was to get stable grammars ready, about two years
>> ago, and they are also hard to test. You can only test the grammar and the
>> generated code after having written thousands of lines derived code and
>> test that. This is not unit-testing. There is a lot of untested code in a
>> parser.
>>
>> I know from own experience, I already wrote a few times an ADL parser,
>> also other parsers, in Java and golang, it takes a year or more. Pieter is
>> working two years on it, of course not every day, but still. It is really a
>> lot of complex code. I remember a year ago he was using a visitor pattern,
>> now he left that. That was quite a big change. While doing it he finds out,
>> and he does a very good job. He is a very good programmer but with a
>> difficult task.
>>
>> And even small updates in a grammar can cause great code change, many
>> difficulties.
>> It does, in my opinion, not belong in a modern programming environment
>> where simplicity, maintainability and testability are important goals.
>>
>> Only changing a few simple paradigms can make thousands of lines of code
>> difference.
>>
>> The elegance of proven technology of worldwide programming effort over
>> many years. The simplicity of JSON guarantees easy controllable and
>> maintainable (sustainable) code.
>>
>> But, as said, for purpose of readability is it easy to serialize to ADL
>> code, if that is an argument.
>>
>> Why do I write all this.
>>
>> I am writing a generic multi purpose BMM/AOM kernel as a hobby project, I
>> work an hour a day on it, sometimes less, I have a job also.
>>
>> I do not want to write an ADL parser because I don't need it. It saves
>> months of work. The code I write, which can also serve OpenEhr or ISO13606
>> or CIMI in any version, or accountancy software or many other can be read
>> by a novice programmer, so simple it is.
>>
>> And I think that is how code should be. Easy to test, easy to debug, easy
>> to read, easy to understand.
>>
>> That is my story, I wanted to see how other people think about these
>> ideas, thanks for sharing your opinions.
>>
>> Best regards
>> Bert
>>
>> Sent from my Xperia™ by Sony smartphone
>>
>>
>>  Bert Verhees wrote 
>>
>> Sent from my Xperia™ by Sony smartphone
>>
>>
>>  Original Message 
>> Subject: Re: JSON for definitions-notation
>> Sent: 15 Feb 2019 22:46
>> From: Bert Verhees 
>> To: Pieter Bos 
>> Cc:
>>
>> Not many people find archetypes readable. I can read them and I have done
>> that many times, but most modelers I know are lost in a second when they
>> see ADL text, I have seen that many times too. But it is more readable than
>> Xml or JSON, I agree.
>>
>> For readability I would like to promote a documentation protocol, modeling
>> tooling should take care for that. That should not be the purpose of an
>> archetype.
>>
>> The archetypes in code are for machine processing, that should be the main
>> purpose, and this purpose should be exercised to a maximum of simplicity
>> and efficiency.
>>
>> I was thinking about the type information ADL has, if it has function in
>> validating datasets.
>>
>> I don't think so, and I think it can be omitted. For va

Re: JSON for definitions-notation

> The folks doing CIMI use at least the JSON mode. It also generates XML, via 
> custom serialiser.
> One of the jobs I never completed is a deserialiser for the 3 regular 
> formats, but it is nearly trivial. 

Exactly my point, I completely agree with this.  

Bert

> 
> Venkat Subramaniam, who is a java-guru, said: "Don't walk away from 
> complexity, RUN!!!" ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

RE: FW: Re: JSON for definitions-notation

A few last words on this. 

It is easy for JSON based archetype repository to cooperate with an ADL based 
repository. Serializing of an AOM structure to ADL is very easy to do, this 
counts for the DADL and CADL part. The other way around, to convert the ADL 
definition part to JSON is harder, that involves the parser-code and grammars 
which are hard to maintain. 

It is fragile code. 

I remember how hard it was to get stable grammars ready, about two years ago, 
and they are also hard to test. You can only test the grammar and the generated 
code after having written thousands of lines derived code and test that. This 
is not unit-testing. There is a lot of untested code in a parser. 

I know from own experience, I already wrote a few times an ADL parser, also 
other parsers, in Java and golang, it takes a year or more. Pieter is working 
two years on it, of course not every day, but still. It is really a lot of 
complex code. I remember a year ago he was using a visitor pattern, now he left 
that. That was quite a big change. While doing it he finds out, and he does a 
very good job. He is a very good programmer but with a difficult task. 

And even small updates in a grammar can cause great code change, many 
difficulties. 
It does, in my opinion, not belong in a modern programming environment where 
simplicity, maintainability and testability are important goals. 

Only changing a few simple paradigms can make thousands of lines of code 
difference. 

The elegance of proven technology of worldwide programming effort over many 
years. The simplicity of JSON guarantees easy controllable and maintainable 
(sustainable) code. 

But, as said, for purpose of readability is it easy to serialize to ADL code, 
if that is an argument. 

Why do I write all this. 

I am writing a generic multi purpose BMM/AOM kernel as a hobby project, I work 
an hour a day on it, sometimes less, I have a job also. 

I do not want to write an ADL parser because I don't need it. It saves months 
of work. The code I write, which can also serve OpenEhr or ISO13606 or CIMI in 
any version, or accountancy software or many other can be read by a novice 
programmer, so simple it is. 

And I think that is how code should be. Easy to test, easy to debug, easy to 
read, easy to understand. 

That is my story, I wanted to see how other people think about these ideas, 
thanks for sharing your opinions. 

Best regards 
Bert 

Sent from my Xperia™ by Sony smartphone

 Bert Verhees wrote 

>
>
>Sent from my Xperia™ by Sony smartphone
>
> Original Message 
>Subject: Re: JSON for definitions-notation
>Sent: 15 Feb 2019 22:46
>From: Bert Verhees 
>To: Pieter Bos 
>Cc: 
>
>Not many people find archetypes readable. I can read them and I have done that 
>many times, but most modelers I know are lost in a second when they see ADL 
>text, I have seen that many times too. But it is more readable than Xml or 
>JSON, I agree. 
>
>For readability I would like to promote a documentation protocol, modeling 
>tooling should take care for that. That should not be the purpose of an 
>archetype. 
>
>The archetypes in code are for machine processing, that should be the main 
>purpose, and this purpose should be exercised to a maximum of simplicity and 
>efficiency. 
>
>I was thinking about the type information ADL has, if it has function in 
>validating datasets. 
>
>I don't think so, and I think it can be omitted. For validating-purpose it is 
>not needed. 
>An archetype is a tree of properties to properties ending via cardinality to 
>leaf nodes. That is the information that is needed and JSON can deliver that 
>without diverging from the object dump idea. All that information is already 
>in AOM. This has as result that archetypes can be read in AOM without need of 
>parsing. 
>
>I was also thinking about the name-convention, but that is a reference model 
>(BMM) issue. The naming convention in the reference model will be used in 
>datasets. 
>
>BMM is very powerful, it extends the purpose of reference models and 
>archetypes to virtually every domain, also OpenEhr . 
>
>It is in fact a wonderful invention, especially in combination with NoSql 
>databases, but it needs a simplicity overhauling for efficiency and general 
>connection to programming eco systems or standards can be achieved by using 
>its conventions. 
>
>Bert
>
>Sent from my Xperia™ by Sony smartphone
>
> Pieter Bos wrote 
>
>>Archie offers a json serializer and deserializer. For Odin they are present 
>>as well, but has not been tested with archetypes, may need a small bit of 
>>work. Yaml should be a matter of adding a dependency and configuring it.
>>We're still working on XML - the bindings are there and it works, but the AOM 
>>schemas have not been finished yet so there w

FW: Re: JSON for definitions-notation

Sent from my Xperia™ by Sony smartphone

 Original Message 
Subject: Re: JSON for definitions-notation
Sent: 15 Feb 2019 22:46
From: Bert Verhees 
To: Pieter Bos 
Cc: 

Not many people find archetypes readable. I can read them and I have done that 
many times, but most modelers I know are lost in a second when they see ADL 
text, I have seen that many times too. But it is more readable than Xml or 
JSON, I agree. 

For readability I would like to promote a documentation protocol, modeling 
tooling should take care for that. That should not be the purpose of an 
archetype. 

The archetypes in code are for machine processing, that should be the main 
purpose, and this purpose should be exercised to a maximum of simplicity and 
efficiency. 

I was thinking about the type information ADL has, if it has function in 
validating datasets. 

I don't think so, and I think it can be omitted. For validating-purpose it is 
not needed. 
An archetype is a tree of properties to properties ending via cardinality to 
leaf nodes. That is the information that is needed and JSON can deliver that 
without diverging from the object dump idea. All that information is already in 
AOM. This has as result that archetypes can be read in AOM without need of 
parsing. 

I was also thinking about the name-convention, but that is a reference model 
(BMM) issue. The naming convention in the reference model will be used in 
datasets. 

BMM is very powerful, it extends the purpose of reference models and archetypes 
to virtually every domain, also OpenEhr . 

It is in fact a wonderful invention, especially in combination with NoSql 
databases, but it needs a simplicity overhauling for efficiency and general 
connection to programming eco systems or standards can be achieved by using its 
conventions. 

Bert

Sent from my Xperia™ by Sony smartphone

 Pieter Bos wrote 

>Archie offers a json serializer and deserializer. For Odin they are present as 
>well, but has not been tested with archetypes, may need a small bit of work. 
>Yaml should be a matter of adding a dependency and configuring it.
>We're still working on XML - the bindings are there and it works, but the AOM 
>schemas have not been finished yet so there will be changes, see the 
>specifications-ITS-XML repository on GitHub for details.
>
>One could argue ADL is easier to read and write by humans than json, yaml, 
>Odin or XML. The other formats have a lot more tools available. Good thing we 
>have both.
>
>Regards,
>
>Pieter Bos
>
>
>
>Op 15 feb. 2019 20:41 schreef Thomas Beale :
>
>JSON, YAML and ODIN are all just object-dump serial formats that result from 
>traversing an in-memory object graph, so it is a generic operation to generate 
>them from tools (XML is more problematic due to being irregular in many ways 
>and being schema-dependent).
>
>In the case of archetypes, the dump is just of objects that are instances of 
>the 
>AOM<https://specifications.openehr.org/releases/AM/latest/AOM2.html#_the_archetype_package>,
> i.e., ARCHETYPE, C_ATTRIBUTE, various kinds of C_OBJECT and so on.
>
>The ADL Workbench has an export mode (for I think around 5 yeras) that 
>generates the first 3 for any archetype, and also a whole archetype library. 
>The folks doing CIMI use at least the JSON mode. It also generates XML, via 
>custom serialiser.
>
>One of the jobs I never completed is a deserialiser for the 3 regular formats, 
>but it is nearly trivial. I am not sure if Archie or Marand's ADL-designer 
>tools do the same but I think it should be trivial for them to implement as 
>well.
>
>I will look into this again...
>
>- thomas
>
>On 15/02/2019 18:51, Bert Verhees wrote:
>I always admired OpenEhr for its ability to notate archetype-definitions and 
>now also BMM definitions in any type.
>
>I saw experiments in XML, but the official endorsed notation language is ADL.
>
>
>I wonder, would it also be possible to write archetypes and reference-models 
>in JSON?
>
>If so, it would save us tons of code, no grammars needed, no parsers needed. 
>Many programming languages support JSON out of the box, with only some 
>annotations needed. NoSQL Databases often support JSON, and have their own 
>JSON-path based hierarchical query-languages.
>
>Venkat Subramaniam, who is a java-guru, said: "Don't walk away from 
>complexity, RUN!!!"
>
>But Einstein said: "Everything Should Be Made as Simple as Possible, But Not 
>Simpler"
>
>So the question is: Are there any technical objections to express archetypes 
>and reference-models in JSON?
>
>Best regards
>
>Bert Verhees
>
>
>___
>openEHR-technical mailing list
>openEHR-technical@lists.openehr.org<mailto:openEHR-technical@lists.o

Fwd: JSON for definitions-notation

The object dump is a common use-case for JSON.

There a few things that are needed more then the object dump.

What we would still need is standardised naming-notation of classes and
properties, so there cannot be a conflict on that. I think the current
format used in OpenEhr is very good, although not the same convention as in
Java, but that is a minor issue.

JSON can, besides using for object-dumps offer also space for
meta-information, like type-information. The class name of an object for
example, is such information which programmers often use. In Java it is by
the instanceof-operator.
Other ecosystems have similar operators.

So to use JSON for archetype notation some things must be agreed on. I
would be happy with such agreements.

The advantages of JSON are huge. Except from the easy standard
implementation there are many libraries and very efficient. Also inserting
JSON in JSON makes flattening and template creation a matter of a few lines
of code.

And validating routines can partly be easily generated in memory and
applied on JSON datasets.
The only part that need grammar and parsing are the leaf and cardinality
constraints. These are easy to define and parse and can be extracted from
the current grammars.

Bert


 Thomas Beale wrote 

JSON, YAML and ODIN are all just object-dump serial formats that result
from traversing an in-memory object graph, so it is a generic operation to
generate them from tools (XML is more problematic due to being irregular in
many ways and being schema-dependent).

In the case of archetypes, the dump is just of objects that are instances
of the AOM
<https://specifications.openehr.org/releases/AM/latest/AOM2.html#_the_archetype_package>,
i.e., ARCHETYPE, C_ATTRIBUTE, various kinds of C_OBJECT and so on.

The ADL Workbench has an export mode (for I think around 5 yeras) that
generates the first 3 for any archetype, and also a whole archetype
library. The folks doing CIMI use at least the JSON mode. It also generates
XML, via custom serialiser.

One of the jobs I never completed is a deserialiser for the 3 regular
formats, but it is nearly trivial. I am not sure if Archie or Marand's
ADL-designer tools do the same but I think it should be trivial for them to
implement as well.

I will look into this again...

- thomas
On 15/02/2019 18:51, Bert Verhees wrote:

I always admired OpenEhr for its ability to notate archetype-definitions
and now also BMM definitions in any type.

I saw experiments in XML, but the official endorsed notation language is
ADL.


I wonder, would it also be possible to write archetypes and
reference-models in JSON?

If so, it would save us tons of code, no grammars needed, no parsers
needed. Many programming languages support JSON out of the box, with only
some annotations needed. NoSQL Databases often support JSON, and have their
own JSON-path based hierarchical query-languages.

Venkat Subramaniam, who is a java-guru, said: "Don't walk away from
complexity, RUN!!!"

But Einstein said: "Everything Should Be Made as Simple as Possible, But
Not Simpler"

So the question is: Are there any technical objections to express
archetypes and reference-models in JSON?

Best regards

Bert Verhees


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

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

JSON for definitions-notation

I always admired OpenEhr for its ability to notate archetype-definitions 
and now also BMM definitions in any type.


I saw experiments in XML, but the official endorsed notation language is 
ADL.



I wonder, would it also be possible to write archetypes and 
reference-models in JSON?


If so, it would save us tons of code, no grammars needed, no parsers 
needed. Many programming languages support JSON out of the box, with 
only some annotations needed. NoSQL Databases often support JSON, and 
have their own JSON-path based hierarchical query-languages.


Venkat Subramaniam, who is a java-guru, said: "Don't walk away from 
complexity, RUN!!!"


But Einstein said: "Everything Should Be Made as Simple as Possible, But 
Not Simpler"


So the question is: Are there any technical objections to express 
archetypes and reference-models in JSON?


Best regards

Bert Verhees


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

Re: Error in website

2019-01-04 Thread Bert Verhees

Thanks :-) 

Sent from my Xperia™ by Sony smartphone

 Thomas Beale wrote 

>Ths XSD and JSON repo folders did not have index files - we have added 
>some simple ones to display everything. We'll improve these over time.
>
>- thomas
>
>On 04/01/2019 14:20, Bert Verhees wrote:
>> Don't know where to tell this, but there is something not okay on:
>>
>> https://specifications.openehr.org/releases/ITS/latest/index
>>
>> Many links don't work 
>
>
>___
>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

Error in website

2019-01-04 Thread Bert Verhees


Don't know where to tell this, but there is something not okay on:

https://specifications.openehr.org/releases/ITS/latest/index

Many links don't work


Bert



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

Re: openEHR on FHIR and vice versa

2018-12-17 Thread Bert Verhees

In fact is this a bit of exciting question. On one side, the OpenEhr
community has the point of view that OpenEhr is static, CKM rules and is
planned to cover the whole information requirement for healthcare. Do not
invent your own archetypes, but use the high quality CKM archetypes is an
advice I often hear, and for which is good reasoning.

But if that is the case, then there is only need for a one time mapping
between the CKM archetypes and FHIR.

So, there is not really a problem.

But on the other hand, if you have the opinion that CKM is something nice
but you think that you can do better, or you need something else (for
example wellness and sports archetypes), then you need to write your own
FHIR mapping.

But again, people only using CKM only need a one time mapping between an
archetype and a FHIR resource which can last forever. The waiting is for
the moment that CKM will create space to create these mappings.

I wonder, would templates be a good way to arrange this?

I am very interested in opinions about this

Best regards
Bert Verhees

Op ma 17 dec. 2018 19:27 schreef Pablo Pazos  I also did some mapping work FHIR -> openEHR using Mirth, but this is
> ad-hoc, no automatic mapping yet, for that you need to define a lot of
> constraints to make it work automatically. Maybe some semi-automatic tool
> come out in the future, assisting architects on doing such mappings, either
> way some kind of human intervention will be needed to define mapping
> criteria when there are  1 to * mapping possibilities.
>
> On Fri, Dec 14, 2018 at 8:01 AM Jan-Marc Verlinden 
> wrote:
>
>> We are doing something similar at the moment. but instead of doing this
>> inside the archetype we are considering the use of an external mapping tool
>> like Mirth Connect or OpenHIM. But we are not there yet.. :-)
>>
>> Jan-Marc Verlinden
>> www.medrecord.io
>> www.medsafe.io
>> 0653785650
>>
>>
>> Op vr 14 dec. 2018 om 11:49 schreef Diego Boscá :
>>
>>> Hello Georg,
>>>
>>> The main result of that paper was supporting FHIR as a reference model
>>> to define archetypes (you can do that with no limitations on the currently
>>> available tool). There is no openEHR archetype <-> FHIR profile service
>>> yet, although I believe that providing a openEHR -> FHIR generical
>>> transformation could be feasible.
>>> Most of the results of this work are available as import/export
>>> functions in LinkEHR: Importing StructureDefinitions should work for most
>>> things (in fact, I have been updating this part recently and will have
>>> better support for STU3 in next LinkEHR version we publish). The export
>>> feature is in the original DSTU format though, I assume we should go
>>> further and generate StructureDefinitions as in STU3. For the
>>> transformation of data instances, as I said we use archetypes as way to
>>> express FHIR profiles and resources, so transforming between them is no
>>> more difficult than transforming between openEHR, CDA, ISO13606, ODM, etc.
>>> which you can do with the LinkEHR studio (FYI, the LinkEHR Studio version
>>> available on the website allows you to test this mapping/transformation
>>> part, the only thing you won't be able to do is to export the output XQuery
>>> transformation)
>>>
>>> Regards
>>>
>>> El vie., 14 dic. 2018 a las 11:19, Georg Fette (<
>>> georg.fe...@uni-wuerzburg.de>) escribió:
>>>
>>>> Hello,
>>>> I have just read the paper "Combining Archetypes with Fast Health
>>>> Interoperability Resources in Future-proof Health Information Systems",
>>>> in which the representation of openEHR archetypes as FHIR profiles is
>>>> presented. As I am also trying to use this approach and I wonder if
>>>> there are working and publicly available applications (possibly emerged
>>>> from the above mentioned research) that use that approach ? I am
>>>> especially interested in:
>>>> - transforming openEHR archetypes into FHIR profiles
>>>> (StructureDefinitions) and storing them in a FHIR server.
>>>> - transforming FHIR profiles into openEHR archetypes and storing them
>>>> in
>>>> an openEHR server.
>>>> - transforming openEHR archetype instances into FHIR resources
>>>> (Bundles)
>>>> and storing them in a FHIR server.
>>>> - transforming FHIR resources into openEHR instances and storing them
>>>> in
>>>> an openEHR server.
>>>> Greetings
>>>> Georg
>>>>
>>>> --
>&

Re: Use of LinkEHR to create OPTs like we do with Template designer

2018-12-13 Thread Bert Verhees


On 13-12-18 16:13, Thomas Beale wrote:

They are already working on a local install version for that.


Good to hear, I think, that should be announced better, and with roadmap.

Bert



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

Re: Use of LinkEHR to create OPTs like we do with Template designer

2018-12-13 Thread Bert Verhees


On 13-12-18 13:08, Thomas Beale wrote:
No, it is under heavy development, and will definitely become the main 
tool for modellers - 


I don't hope so, it would be bad for the OpenEhr-promotion.

It forces people to make their templates known to a third party website, 
I can imagine that commercial companies do not want to do this.


Their data-structures are often regarded as their crown-jewels.

Best regard

Bert Verhees



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

Re: Reference Model as Archetypes ?


On 12-12-18 15:44, Diego Boscá wrote:
When I say official I refer to AOM. If AOM/ADL let's you say something 
we try to support it. We always 'eat' what others tools produce, and 
have implemented export mechanisms to be compatible with the things 
other tools can handle. In this particular case you mentioned, an 
exported archetype from LinkEHR can be opened in any other archetype 
editor directly. We also gave support for OPT & OET import/export, and 
even OPTs generated this way are virtually identical to the ones 
coming from the template designer.


So yes, we have tweaked the parser to support more things, but the 
archetype creation is completely RM driven (archetypes created with 
LinkEHR are always compliant with the RM you choose). That created 
archetype can be then saved to different representations depending of 
your needs (ADL for specific tools, XML, etc).


Congratulations, I think now nobody has any doubt.

Bert



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

Re: Reference Model as Archetypes ?


On 12-12-18 14:49, Diego Boscá wrote:
These are modifications on the parser, which parses more things than 
your standard parser. In fact, the editor supports legal things in ADL 
that other parsers don't (e.g. explicit node identifiers or 
existence). The generated ADL is completely fine ADL. There are tools 
that don't comply with this general ADL, and we provided an export 
version of archetypes that produces a modified version of the ADL 
syntax that other older and not maintained tools can parse.

If you want to call this subset "official archetypes" be my guest.


The word "official" was used by you, I used it (in quotes) to indicate 
that we refer to the same.


But it may get confusing, also because in the past there were 
discussions about LinkEhr and the Ocean archetype-editor which had 
different interpretations of the prevailing definitions. They did not 
always eat each others archetypes.


I think at this point it is important to state in a simple way, then 
there will be no reason for doubt about intentions:


Does the LinkEhr editor produce archetypes which are always intended to 
be completely conforming the official ADL/AOM and RM definitions?


Best regards

Bert



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

Re: Reference Model as Archetypes ?


On 12-12-18 13:48, Diego Boscá wrote:
The official one, these are 'hacks' that allow you to handle 
requirements and edge cases only present in these RM archetypes


Diego, I don't want to be harsh about LinkEhr, which is a very strong 
product. But this situation raises questions. I already had this 
discussion a few times.


Especially because it is not mentioned on the LinkEhr website that it 
does not support the official OpenEhr out of the box.


You should have an option in the application for creating "official" 
archetypes, this to avoid confusion.


I think it is very good that you fix issues you experience, but this 
way, by implementing without explicit notifying does not seem the royal way.


It is bad, because in this way, the OpenEhr-software-ecosystem-base may 
become too narrow, and it is easy to fix by you, as you indicate to 
Georg Fette


Best regards

Bert

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

Re: Reference Model as Archetypes ?


On 12-12-18 12:53, Diego Boscá wrote:
We used that one as a basis and generalized mostly to allow the 
special RM 'at' codes we created. I can send you the modified grammar 
or the parser if you want.


Wouldn't that disturb interoperability processes? One could wonder: 
Which one is the right grammar, which one is the right parser?


Bert



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

Re: Parsing of Archetypes/Templates


On 12-11-18 18:40, Bert Verhees wrote:

>> Another very important restriction for using XML Schema, in my opinion,
>> is that you cannot have two or more elements with the same name but a
>> different data type. This data type must be in detail the same. XML Schema
>> regards an Element with a Dv_Text as a different datatype from an Element
>> with a Dv_CodedText.
>>
>> Both elements will be called "items" in an XML schema representing an
>> OpenEhr data structure, and thus is not allowed having them different
>> details in data types.


This already happens in a Item-List, so the constraint is quite easy to 
trigger.



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

Re: Parsing of Archetypes/Templates


On 12-11-18 17:59, Thomas Beale wrote:



On 12/11/2018 16:04, Bert Verhees wrote:

On 12-11-18 16:13, Thomas Beale wrote:
you can, it's called a Template Data Schema (TDS), and is generated 
from the Template Designer and I think the new Marand ADL-designer. 
Its intended exactly for checking data sets...


Of course you can write any validation tool you want,  but you cannot 
do this and still conform to the XML Schema standard, that is why 
Schematron became important. With Schematron you can validate 
anything. As I wrote this morning, LinkEhr also generates Schematron 
for validation purpose.


this already works (for nearly 10 years) and it validates against the 
XML schema standard. What it doesn't do is validate everything you 
want to validate, i.e. not all things in the archetypes. But it's good 
enough most of the time.



I am in the proud possession of the book, "Definitive XML Schema 1.1" by 
Priscilla Walmsley. We had this discussion a few times already

I quote from
https://www.mail-archive.com/search?q=walmsley=openehr-technical%40lists.openehr.org
https://www.mail-archive.com/openehr-technical@lists.openehr.org/msg07405.html


Another very important restriction for using XML Schema, in my opinion,
is that you cannot have two or more elements with the same name but a
different data type. This data type must be in detail the same. XML Schema
regards an Element with a Dv_Text as a different datatype from an Element
with a Dv_CodedText.

Both elements will be called "items" in an XML schema representing an
OpenEhr data structure, and thus is not allowed having them different
details in data types.


Sorry for the funny font,

To do things properly, I agree, you would probably use Schematron + 
XSD, or personally I have always thought that Schematron + Relax-NG 
would be better.


Also I went through that path, with Relax NG, I struggled quite some 
time with this, and not me alone. Ask Diego why LinkEhr does not export 
RelaxNG or XML Schema but Schematron as validation files (although, it 
was like this a few years ago, it still is so in the version I have).


The XSD standard-constraint mentioned above also becomes visible with 
standard XML libraries. If I would have time I would proof it to you in 
a simple way.




whether this is the real requirement being talked about here may be 
another question.


You are right, it was not what was asked, still I thought it would be 
interesting for others to know that there is a JSON Schematron parser 
(instead of an XML Schematron-parser), which can be used to validate 
JSON OpenEhr-datasets against archetypes/templates.


that might be an interesting thing to have in the openEHR toolkit. We 
are just now revising and re-organising all the openEHR XSDs, and also 
adding in some JSON-schemas. Any related artefacts that anyone wants 
to contribute, or fragments that could be used in something larger 
would be appreciated - it will all get posted in the 
specifications-ITS-XML git repo under the usual CC licence.


OpenEhr uses XSD schemas for class descriptions, there is no problem at 
all. It is even an often used methodology in the Java world to 
describe/generate class-interfaces. The problem is when using XML Schema 
for validation of archetyped XML-data. But again, this was not the 
problem the question was initially about. Sorry for the confusion.


Bert


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

Re: Parsing of Archetypes/Templates


On 12-11-18 16:13, Thomas Beale wrote:


On 12/11/2018 09:44, Bert Verhees wrote:


Sorry, I first replied to Pieter Bos only, now to the list. Pieter 
already replied to me that the question was not about XSD to check 
datasets was .


So, read my reply, for those interested in easy validating datasets:

It is possible to have an XSD to describe the AOM, but you cannot 
have an XSD to describe an archetype and check a dataset with it.


you can, it's called a Template Data Schema (TDS), and is generated 
from the Template Designer and I think the new Marand ADL-designer. 
Its intended exactly for checking data sets...


Of course you can write any validation tool you want,  but you cannot do 
this and still conform to the XML Schema standard, that is why 
Schematron became important. With Schematron you can validate anything. 
As I wrote this morning, LinkEhr also generates Schematron for 
validation purpose.




whether this is the real requirement being talked about here may be 
another question.


You are right, it was not what was asked, still I thought it would be 
interesting for others to know that there is a JSON Schematron parser 
(instead of an XML Schematron-parser), which can be used to validate 
JSON OpenEhr-datasets against archetypes/templates.


I wrote an AOM(OpenEhr/CEN13606)-Schematron-validation-generator years 
ago, exactly for this reason, I must have the sourcecode somewhere. Good 
for Marand to have validation too, because checking data-sets before 
storing them is an important responsibility of an OpenEhr-kernel.


Bert



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

Re: Parsing of Archetypes/Templates

Sorry, I first replied to Pieter Bos only, now to the list. Pieter 
already replied to me that the question was not about XSD to check 
datasets was .


So, read my reply, for those interested in easy validating datasets:

It is possible to have an XSD to describe the AOM, but you cannot have 
an XSD to describe an archetype and check a dataset with it.


Archetypes can have logical constructs which are not allowed in XSD. It 
has to do with elements with the same name on the same level, that is 
not allowed in XSD, even not when there are different attributes.


You can use Schematron to check an archetyped XML dataset. I believe the 
LinkEHR editor generates such Schematrons.


I also found Schematron validator for JSON, I think that this is very 
interesting for some kernel software developers, because XML is slowly 
becoming something of an previous era.


https://www.npmjs.com/package/jsontron

Good luck with it.

Bert.

On 12-11-18 09:30, Pieter Bos wrote:

Hello George,

If you are looking for something to handle ADL 2 archetypes - the most 
recent version -, have a look at https://github.com/opener/archie . It 
is a java library that can parse archetypes, flatten and validate  
them, create operational  templates and more.


Are you using the openehr reference model, or something else like fihr?

Although Archie can parse and serialize archetypes in XML, archetypes 
are usually stored as ADL. This is a custom more readable format. Of 
course you can then easily convert it to XML or Json to work with them 
in other tools where you do not have an ADL parser ready.


Note that for ADL 2 as far as I know there is no official XSD released 
yet, so it is possible you run into compatibility problems with XML. 
For ADL 1.4 this is not a problem.


Regards,

Pieter Bos


Op 12 nov. 2018 09:18 schreef Georg Fette :
Hello,
For a project we want to create a generic mechanism to transform
archetypes into FHIR Logical Models, so we can store, retrieve and query
archetype instance with FHIR tools (CQL, FHIR-REST-API-query). At the
moment we just want to read/write archetypes and not archetype
instances. We are looking for existing components to parse and process
archetypes. I have some questions I encountered related to these issues:
- I have found several projects that store openEHR-data (archetypes as
well as archetype instances) into different data substrates (Neo4J, ARM
(archetype relational mapping), EtherCIS). Although I have not yet
looked at the code of these projects I assume that they take an
archetype XML-file, parse it and thus create a runtime object of the
archetype. That runtime object can then be given as a parameter to a
persistence layer (e.g. JOOQ, Hibernate, etc.). In order to reuse
something from already existing projects I am looking for a parser that
creates a runtime object from an archetype-XML-String, so we can write
our own components that transform it into a FHIR runtime object. The
component we are looking for should preferably be written in Java, as
this is our language of choice in our project.
- I am not ye sure if we are looking for a method to transform
archetypes, templates or operational templates into FHIR related
structures, as I am not yet that familiar with which data structure is
preferably used for which kind of task. Therefore, component that,
instead of archetypes, parse templates or operational templates would be
appreciated as well.
Greetings
Georg

--
-
Dipl.-Inf. Georg Fette  Raum: B001
Universität Würzburg    Tel.: +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



--
*Bert Verhees*
Software developer, architect

Profile: https://www.bertverhees.nl/

Twitter: https://twitter.com/VerheesBert
LinkedIn: https://www.linkedin.com/in/bertverhees/
Email: bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>
Mobile: +31 06 28050294
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: e-health services landscape - initial proposal, open forum

2018-10-29 Thread Bert Verhees

The reason I come to this is that services have a semantic meaning, also
the patient summary has.

And trend is that data in an healthcare application tend to be first
patient centric and than around that patient is a cloud of problems. I
think there is more, for example lifestyle.

But I already repeated this many times, and I guess application developers
will need to learn this the hard way. It is not just OpenEhr, it is just
that I feel involved with OpenEhr.

Thank you for coming back to this, I will await further discussions.

Best regards
Bert

On Mon, 29 Oct 2018, 08:27 Thomas Beale,  wrote:

> As mentioned elsewhere, while I completely agree on the lifestyle / sports
> / wellness needs in the wider e-health context, at the moment I am not sure
> if special SOA services are needed or not, since these kinds of data can be
> committed to the EHR using the generic EHR service, just as for any other
> kind of data - it's just different archetypes. It may be that special
> services for e.g. performance tracking or whatever are needed, but for now
> I'm assuming all that stuff is done by applications, not services.
>
> - thomas
>
> On 23/10/2018 22:10, Bert Verhees wrote:
>
>
> I miss lifestyle and sport-services which are not explicitly problem
> related. Maybe others have other suggestions, but I like to focus on these.
> I think that is the near future, and not already planning them in will be a
> missed chance. The meaning of the term Healthcare will change to its true
> meaning. Care related to Health, not only illness. Lifestyle data will be
> important, already now insurance companies are registering if customers
> smoke or do sport, and which sport. Some people write down everything they
> eat.
>
> People use their smartphone to communicate and exchange information.
> Interestingly, an increasing number of people collect health data on their
> smartphone such as information about their mood, activity level, nutrition
> or vital signs including blood pressure or blood glucose levels. Medical
> research could greatly benefit from these ‘real life’ data. I think OpenEhr
> must be prepared for this to come, give it room, embrace it.
>
> The same counts for archetypes, there are no archetypes on CKM which are
> fit to register these kind of things.
>
> I had this discussion already a few times on OpenEhr mailinglists, I only
> got laughters as reply, that is why I hesitate to discuss it here, but with
> this, I give it one more chance, just for fun, not expecting any serious
> result.
>
>
> ___
> 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: e-health services landscape - initial proposal, open forum

2018-10-25 Thread Bert Verhees

That is very helpful. I think too that it will be beneficial for OpenEhr.
I will send you requirements within two weeks, and then we see where we go
from there,

Thanks very much for helping
Bert

Op do 25 okt. 2018 09:08 schreef Heather Leslie <
heather.les...@atomicainformatics.com>:

> I like the idea of some of the archetypes being compared to good wines 
>
>
>
> Another alternative is to submit the requirements you have identified,
> maybe best by email to me, and we can see how we might best be able to
> support you. It might not be a rapid turn around, though. I think getting
> these archetypes into good shape would be useful to many app developers.
>
>
>
> Would that be helpful to you?
>
>
>
> Cheers
>
>
>
> Heather
>
>
>
> *From:* openEHR-technical  *On
> Behalf Of *Bert Verhees
> *Sent:* Thursday, 25 October 2018 5:24 PM
> *To:* For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> *Subject:* Re: e-health services landscape - initial proposal, open forum
>
>
>
> Thanks for your advice, Heather. To be honest about this. The problem is
> that I did not study medical informatics, and I am not sure that archetypes
> I write will be regarded as good enough to stand in the showcase. I was
> hoping to get some interested to help with that, and then someone who is
> regarded as knowledgeable to get them in the place and keep them there.
> Because if that fails the work has been done in vain. And I have a busy
> life.
>
>
>
> But that plan failed. So now plan B. I have found decent datamodels to
> register different kind of sportactivities, and the archetypes you list
> will certainly help. So maybe I give it a try and people will after reading
> this, judge my work mildly.
>
>
>
> So thanks again, after my holiday (tomorrow I go), I will give it a try. I
> have already written quite a few archetypes, of reasonable quality, but of
> course not as matured as the good wines from CKM.
>
>
>
> best regards
>
> Bert
>
> Op do 25 okt. 2018 07:26 schreef Heather Leslie <
> heather.les...@atomicainformatics.com>:
>
> Hi Bert,
>
>
>
> The only way archetypes get included in CKM is that someone builds them
> and offers them for sharing. And scope for all archetypes includes your use
> case of consumer entered data, where it is appropriate. So if something you
> need is not there please work actively with us to improve the situation.
>
>
>
> I suggest that you propose candidate archetypes to CKM where they don’t
> exist or make change requests to existing ones where they need improvement.
>
>
>
> Consider:
>
>- Lifestyle factors -
>https://ckm.openehr.org/ckm/#showArchetype_1013.1.1648
>- Story/History - https://ckm.openehr.org/ckm/#showArchetype_1013.1.68.
>Named ‘story’ precisely to be inclusive of consumer entered data.
>- Goal - https://ckm.openehr.org/ckm/#showArchetype_1013.1.124
>- Physical activity summary -
>https://ckm.openehr.org/ckm/#showArchetype_1013.1.2877
>- Tobacco smoking summary -
>https://ckm.openehr.org/ckm/#showArchetype_1013.1.2466
>- Smokeless tobacco summary -
>https://ckm.openehr.org/ckm/#showArchetype_1013.1.2817
>- Tobacco use - https://ckm.openehr.org/ckm/#showArchetype_1013.1.1629
>– needs to be internalised from the old NEHTA CKM and updated with more
>recent patterns
>- Alcohol consumption summary -
>https://ckm.openehr.org/ckm/#showArchetype_1013.1.1521
>- Alcohol intake https://ckm.openehr.org/ckm/#showArchetype_1013.1.216
>– also needs to be updated with more recent patterns
>- Substance use – https://ckm.openehr.org/ckm/#showArchetype_1013.1.146
>- needs an update based on further requirements and finalisation of other
>OBS patters for tobacco and alcohol
>- Food item - https://ckm.openehr.org/ckm/#showArchetype_1013.1.1922
>- Dietary nutrients -
>https://ckm.openehr.org/ckm/#showArchetype_1013.1.2745.
>- Micronutrients -
>https://ckm.openehr.org/ckm/#showArchetype_1013.1.2744
>- Fetal movement -
>https://ckm.openehr.org/ckm/#showArchetype_1013.1.216
>
> And all the others that are applicable across all domains…
>
>- Story
>- Body weight
>- Height
>- Waist circumference
>- BMI
>- Vital signs – Blood pressure, pulse, temperature
>- Family History
>- Problems
>- Adverse reactions
>- Menstrual cycle
>
>
>
> They may not be ready for use out of the box for your purpose or published
> or covering all potential concepts, but there are a considerable number
> that are applicable for use by consumers and are not a b

Re: e-health services landscape - initial proposal, open forum

2018-10-25 Thread Bert Verhees

Thanks for your advice, Heather. To be honest about this. The problem is
that I did not study medical informatics, and I am not sure that archetypes
I write will be regarded as good enough to stand in the showcase. I was
hoping to get some interested to help with that, and then someone who is
regarded as knowledgeable to get them in the place and keep them there.
Because if that fails the work has been done in vain. And I have a busy
life.

But that plan failed. So now plan B. I have found decent datamodels to
register different kind of sportactivities, and the archetypes you list
will certainly help. So maybe I give it a try and people will after reading
this, judge my work mildly.

So thanks again, after my holiday (tomorrow I go), I will give it a try. I
have already written quite a few archetypes, of reasonable quality, but of
course not as matured as the good wines from CKM.

best regards
Bert

Op do 25 okt. 2018 07:26 schreef Heather Leslie <
heather.les...@atomicainformatics.com>:

> Hi Bert,
>
>
>
> The only way archetypes get included in CKM is that someone builds them
> and offers them for sharing. And scope for all archetypes includes your use
> case of consumer entered data, where it is appropriate. So if something you
> need is not there please work actively with us to improve the situation.
>
>
>
> I suggest that you propose candidate archetypes to CKM where they don’t
> exist or make change requests to existing ones where they need improvement.
>
>
>
> Consider:
>
>- Lifestyle factors -
>https://ckm.openehr.org/ckm/#showArchetype_1013.1.1648
>- Story/History - https://ckm.openehr.org/ckm/#showArchetype_1013.1.68.
>Named ‘story’ precisely to be inclusive of consumer entered data.
>- Goal - https://ckm.openehr.org/ckm/#showArchetype_1013.1.124
>- Physical activity summary -
>https://ckm.openehr.org/ckm/#showArchetype_1013.1.2877
>- Tobacco smoking summary -
>https://ckm.openehr.org/ckm/#showArchetype_1013.1.2466
>- Smokeless tobacco summary -
>https://ckm.openehr.org/ckm/#showArchetype_1013.1.2817
>- Tobacco use - https://ckm.openehr.org/ckm/#showArchetype_1013.1.1629
>– needs to be internalised from the old NEHTA CKM and updated with more
>recent patterns
>- Alcohol consumption summary -
>https://ckm.openehr.org/ckm/#showArchetype_1013.1.1521
>- Alcohol intake https://ckm.openehr.org/ckm/#showArchetype_1013.1.216
>– also needs to be updated with more recent patterns
>- Substance use – https://ckm.openehr.org/ckm/#showArchetype_1013.1.146
>- needs an update based on further requirements and finalisation of other
>OBS patters for tobacco and alcohol
>- Food item - https://ckm.openehr.org/ckm/#showArchetype_1013.1.1922
>- Dietary nutrients -
>https://ckm.openehr.org/ckm/#showArchetype_1013.1.2745.
>- Micronutrients -
>https://ckm.openehr.org/ckm/#showArchetype_1013.1.2744
>- Fetal movement -
>https://ckm.openehr.org/ckm/#showArchetype_1013.1.216
>
> And all the others that are applicable across all domains…
>
>- Story
>- Body weight
>- Height
>- Waist circumference
>- BMI
>- Vital signs – Blood pressure, pulse, temperature
>- Family History
>- Problems
>- Adverse reactions
>- Menstrual cycle
>
>
>
> They may not be ready for use out of the box for your purpose or published
> or covering all potential concepts, but there are a considerable number
> that are applicable for use by consumers and are not a bad starting point.
>
>
>
> Kind regards
>
>
>
> Heather
>
>
>
> *From:* openEHR-technical  *On
> Behalf Of *Bert Verhees
> *Sent:* Wednesday, 24 October 2018 6:10 AM
> *To:* openehr-technical@lists.openehr.org
> *Subject:* Re: e-health services landscape - initial proposal, open forum
>
>
>
>
> I miss lifestyle and sport-services which are not explicitly problem
> related. Maybe others have other suggestions, but I like to focus on these.
> I think that is the near future, and not already planning them in will be a
> missed chance. The meaning of the term Healthcare will change to its true
> meaning. Care related to Health, not only illness. Lifestyle data will be
> important, already now insurance companies are registering if customers
> smoke or do sport, and which sport. Some people write down everything they
> eat.
>
> People use their smartphone to communicate and exchange information.
> Interestingly, an increasing number of people collect health data on their
> smartphone such as information about their mood, activity level, nutrition
> or vital signs including blood pressure or blood glucose levels. Medical
> research could greatly benefit

Re: e-health services landscape - initial proposal, open forum

2018-10-23 Thread Bert Verhees

I do not see my message appear on the archive. Maybe it has to do with
formatting, I saw to late that there was quite some formatting in my
previous message. I try replying without formatting.

Sorry if it will appear twice on the list.

I miss lifestyle and sport-services which are not explicitly problem
related. Maybe others have other suggestions, but I like to focus on
these. I think that is the near future, and not already planning them in
will be a missed chance. The meaning of the term Healthcare will change
to its true meaning. Care related to Health, not only illness. Lifestyle
data will be important, already now insurance companies are registering
if customers smoke or do sport, and which sport. Some people write down
everything they eat.

People use their smartphone to communicate and exchange information.
Interestingly, an increasing number of people collect health data on
their smartphone such as information about their mood, activity level,
nutrition or vital signs including blood pressure or blood glucose
levels. Medical research could greatly benefit from these ‘real life’
data. I think OpenEhr must be prepared for this to come, give it room,
embrace it.

The same counts for archetypes, there are no archetypes on CKM which are
fit to register these kind of things.

I had this discussion already a few times on OpenEhr mailinglists, I
only got laughters as reply, that is why I hesitate to discuss it here,
but with this, I give it one more chance, just for fun, not expecting
any serious result.

On 23-10-18 16:58, Thomas Beale wrote:

Every so often I get bored of what I am doing and start trying to draw
one of those 'services roadmap' kind of diagrams. These often pretty
pictures appear in slide presentations, in standards, whitepapers etc,
but are not often used as a tool to help map out the road ahead. We do
however need some sort of vision of the future for staking out new
services. I like my latest version enough that I thought it would be
worth putting up publicly to get reactions and input.

Please comment and/or add content to the wiki page
<https://openehr.atlassian.net/wiki/spaces/spec/pages/357957633/Services+Landscape+for+e-Health>.

- thomas

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

--
*Bert Verhees*
Software developer, architect

Profile: https://www.bertverhees.nl/

Twitter: https://twitter.com/VerheesBert
LinkedIn: https://www.linkedin.com/in/bertverhees/
Email: bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>
Mobile: +31 06 28050294
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: e-health services landscape - initial proposal, open forum

2018-10-23 Thread Bert Verhees

People use their smartphone to communicate and exchange information.
Interestingly, an increasing number of people collect health data on
their smartphone such as information about their mood, activity
level, nutrition or vital signs including blood pressure or blood
glucose levels. Medical research could greatly benefit from these ‘real
life’ data. I think OpenEhr must be prepared for this to come, give it
room, embrace it.

The same counts for archetypes, there are no archetypes on CKM which are
fit to register these kind of things.

On 23-10-18 16:58, Thomas Beale wrote:

Please comment and/or add content to the wiki page
<https://openehr.atlassian.net/wiki/spaces/spec/pages/357957633/Services+Landscape+for+e-Health>.

- thomas

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

--
*Bert Verhees*
Software developer, architect

Profile: https://www.bertverhees.nl/

Re: GDPR and OpenEhr.

2018-09-05 Thread Bert Verhees

On 05-09-18 11:15, GF wrote:

Thomas,

The record can stay where it was.
Only the connection of identifying patient data and the Record-ID
needs to be encrypted.
De-encryption can take place using a key owned and provided by a
notary public.

I don't think that is enough, Gerard, if the record contains DNA
material, or other identifying material.

A 1997 study showed that up to 87% of the U.S. population could be
identify with just zip code, birthdate and gender.
A researcher was able to identify William Weld (Massachusetts Gov.) from
anonymous hospital discharge records.

Today this numbers will be much higher because clinical actions will be
on cell-phones and internet-browsers, and there is much more
linked-information about individuals.

Read this, very interesting:

https://www.forbes.com/sites/adamtanner/2013/04/25/harvard-professor-re-identifies-anonymous-volunteers-in-dna-study/#41635a6892c9

An organization which has no business with your medical data should not
have access to them, not even historical clinical data.
GDPR, were we all talk about, which is the thread of this message, is
mainly build around consent, but what is consent?

There should be more discussion about to get the understanding landing
at normal people:

Click on the image, I found yesterday, to see more images:
https://twitter.com/ianmthompson/status/1037276071002038272

Bert

All must be handled by the Patient-ID server and an official
functionary that is equipped to manage keys in a trusted way.

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

Kattensingel 20
2801 CA Gouda
the Netherlands

On 1 Sep 2018, at 20:28, Thomas Beale <mailto:thomas.be...@openehr.org>> wrote:

I continue to wonder what will happen when a cancer patient (perhaps
in a moment of depression or disaffection with care) asks for the
hard delete, gets better, then has a recurrence a few years later.
What does the health system do when/all the notes are really gone/?

I think a better solution is to create a digital locked room when
such EHRs are put, one-way encrypted with a giant key provided by the
patient. Then when they have regrets, they can ask - nicely - for
their record to come out of cold storage.

Another argument against total deletion is that a) the state has
invested in helping sick patients and b) other citizens have a
potential interest in health records belonging to those in the same
major disease cohort, i.e. diabetes, cystic fibrosis, BRCA1 cancer
etc. Numerous deletions are certainly going to compromise research
that looks at longitudinal Dx v treatments v outcomes. Perhaps
perhaps permanent anonymisation is a better solution in this case,
with the original patient being given the new EHR id.

I think GDPR has some way to go yet in healthcare...

- thomas

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

--
*Bert Verhees*
Software developer, architect
Twitter: https://twitter.com/VerheesBert
LinkedIn: https://www.linkedin.com/in/bertverhees/
Email: bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>
Mobile: +31 06 28050294
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: GDPR and OpenEhr.

2018-09-04 Thread Bert Verhees


On 04-09-18 16:40, Ricardo Correia wrote:

Dear all,

I published recently an attempt to "systematyse" the relation between 
openehr and gdpr.


Thanks very much for sharing, I am sure that the chapter OpenEhr and 
GDPR is not yet to be closed, there is quite some work to do.
Although I have difficulties estimating the consequences, because of the 
concise wording.


I hope that the community shall find its way. OpenEhr must be able to 
run under jurisdiction of the GDPR, and of course also many other 
jurisdictions


Bert



Hope it is useful to you.

Link: http://ebooks.iospress.nl/publication/48760


Regards,

Ricardo Correia

---
Ricardo João Cruz Correia
Professor Auxiliar
ISI: www.researcherid.com/rid/A-2756-2009 
<http://www.researcherid.com/rid/A-2756-2009>
research gate: www.researchgate.net/profile/Ricardo_Cruz-Correia/ 
<https://www.researchgate.net/profile/Ricardo_Cruz-Correia/>
OrcId: orcid.org/-0002-3764-5158 
<http://orcid.org/-0002-3764-5158>
linked-in: pt.linkedin.com/in/ricardojccorreia 
<http://pt.linkedin.com/in/ricardojccorreia%E2%80%8E>‎ 
<http://pt.linkedin.com/in/ricardojccorreia%E2%80%8E>



*MEDCIDS* - Departamento de Medicina da Comunidade, Informação e 
Decisão em Saúde <http://cides.med.up.pt/>
*CINTESIS* - Center for Research in Health Technologies and 
Information Systems <http://cintesis.med.up.pt>

Faculty of Medicine, University of Porto

Tel: (+351) *220 426 909 / *(+351) *225 513 622,* Fax: +351 *225 513 623*
Rua Dr. Plácido da Costa, s/n | 4200-450 Porto | *Portugal*


On Mon, Sep 3, 2018 at 2:26 PM Bert Verhees <mailto:bert.verh...@rosa.nl>> wrote:





In all other contexts the patient can never be forgotten or
deleted. Any legal transaction is subject to archiving laws.
For tax purposes the time period is 5 years in the
Netherlands, I think. Only after these periods as defined by
law the transactions can/must be deleted.


It is true that there are laws which make it necessary to keep
certain data, good example, taxes. I business owner must keep a
record of all financial transactions. I think the GDPR excludes
this from its effect, because laws may not contradict each other.

Thanks for this remark

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



--
*Bert Verhees*
Software developer, architect
Twitter: https://twitter.com/VerheesBert
LinkedIn: https://www.linkedin.com/in/bertverhees/
Email: bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>
Mobile: +31 06 28050294
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: GDPR and OpenEhr.

In all other contexts the patient can never be forgotten or deleted. Any
> legal transaction is subject to archiving laws. For tax purposes the time
> period is 5 years in the Netherlands, I think. Only after these periods as
> defined by law the transactions can/must be deleted.
>

It is true that there are laws which make it necessary to keep certain
data, good example, taxes. I business owner must keep a record of all
financial transactions. I think the GDPR excludes this from its effect,
because laws may not contradict each other.

Thanks for this remark

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

Re: GDPR and OpenEhr.

Karsten, you are right, a clinician, in the most countries is obliged to
keep an EHR. But the law does mostly not say he must keep it at his own
office. So if it is kept at Google or Microsoft, or some smaller PHR
provider, I think this is fine according to the law, but still some
law-changes may be needed.

The fact that the largest five companies in the world agreed to a common
interface/message format and defined dataset must have a good reason. The
reason will be that they want to offer a PHR service, and that in
compliance with GDPR, because 500 million people live in jurisdiction of
GDPR. The tech-companies are getting their part from the multi-billion
market, and they are right, according to their capabilities.

This agreement is not made to be the next EPIC in line and begging at
hospital-doors to implement their software. This service is meant to be
transmural in many ways.

That in some countries, there will be laws to have copies at clinicians
availability can be true, what I wanted to indicate was that it is not
necessary for good healthcare, and also not for medico-legal procedures.
But reality changes slower then possible, and that may be a good thing also.

I think there will not be a PHR service which is to use by clinicians for
coming five years, but the pressure is high. It is, in my opinion, the most
optimal solution for worldwide interoperability regarding to efficiency,
safety and privacy. And it breaks open a new market for appliances which
use data from several sources, it empowers the patients (ehhh
healthcare-consumers).

It really brings healthcare to a new level. GDPR is restrictive but also
gives chances, it makes more possible then was possible before, but in
another way.

Bert

Op ma 3 sep. 2018 om 13:59 schreef Karsten Hilbert :

> On Mon, Sep 03, 2018 at 01:08:41PM +0200, Bert Verhees wrote:
>
> > So, on medico-legal purposes as Ian and Karsten and maybe others referred
> > to, a patient, if he maintains his own PHR, and he likes to delete it, he
> > can never sue a clinician, because, he, himself, destroyed important
> > evidence.
>
> That is certainly not true, and also not what I intended to say.
>
> > For that reason, it is for a clinician not necessary to maintain
> > data-copies from the patient
>
> What ?   Even sub-legal practice law mandates keeping a record :-)
>
> I am sure I misunderstand what you are saying.
>
> > If the clinician needs access to the data, for example, to prepare for a
> > visit next day, he can ask the patient to allow access to the PHR the day
> > before the visit, but these are al infrastructural details, for which
> > solutions can be found.
>
> Not in the real world today.
>
> Karsten
> --
> GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
>
> ___
> 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: GDPR and OpenEhr.

It would be a bad thing to let all patients be restricted in their rights
because one patient, suffering in the past from depression and having a
recurring cancer can get into problems. Some people are emotionally
unstable, they need protection. I don't know the best way, but I would
think of something as the digital locked room. (mentioned here below), but
this should not default happen for all patients.
It is, btw, possible to switch digital locked rooms also when switching
data to a new PHR provider. So that all data remain to be maintained at the
company the patient chooses.

For research purpose, the must also be solutions. People can allow
voluntary access to their data by researchers, this is how it works now. So
in the PHR situation, researchers go to the PHR providers instead of the
clinicians. Not many people will delete all their data without transporting
them to a new PHR provider (if someone wants to do, you can build a net of
safety measures, confirmation time, etc), and for those two or three who
still destroy all, researchers will not have data.

Bert

Op za 1 sep. 2018 om 20:29 schreef Thomas Beale :

> I continue to wonder what will happen when a cancer patient (perhaps in a
> moment of depression or disaffection with care) asks for the hard delete,
> gets better, then has a recurrence a few years later. What does the health
> system do when *all the notes are really gone*?
>
> I think a better solution is to create a digital locked room when such
> EHRs are put, one-way encrypted with a giant key provided by the patient.
> Then when they have regrets, they can ask - nicely - for their record to
> come out of cold storage.
>
> Another argument against total deletion is that a) the state has invested
> in helping sick patients and b) other citizens have a potential interest in
> health records belonging to those in the same major disease cohort, i.e.
> diabetes, cystic fibrosis, BRCA1 cancer etc. Numerous deletions are
> certainly going to compromise research that looks at longitudinal Dx v
> treatments v outcomes. Perhaps perhaps permanent anonymisation is a better
> solution in this case, with the original patient being given the new EHR id.
>
> I think GDPR has some way to go yet in healthcare...
>
> - thomas
>
> On 01/09/2018 18:57, Diego Boscá wrote:
>
> If a patient uses a private health provider then he has the right of
> taking all that information and move to another provider. In that case he
> will want a hard-delete of data. And I hope private health providers are
> also able to use openEHR ;D
> I think we should also review the "consent" mechanisms we have, as they
> probably should also be tweaked to comply with GDPR.
>
>
> ___
> 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: GDPR and OpenEhr.

I promised to come back to some contributions.

So, on medico-legal purposes as Ian and Karsten and maybe others referred
to, a patient, if he maintains his own PHR, and he likes to delete it, he
can never sue a clinician, because, he, himself, destroyed important
evidence. For that reason, it is for a clinician not necessary to maintain
data-copies from the patient (besides this should not be allowed either),
because the patient has an external service which takes care for that. It
is not anymore a clinician's business.

If it comes to a medico-legal procedure, the clinician, or his lawyer,
should have access to all evidence which is important in context of this
procedure. This does not differ from other legal procedures.

If the clinician needs access to the data, for example, to prepare for a
visit next day, he can ask the patient to allow access to the PHR the day
before the visit, but these are al infrastructural details, for which
solutions can be found.

Bert

Op za 1 sep. 2018 om 19:25 schreef Ian McNicoll :

> Hi Bert,
>
> There are certainly some implementations that allow for hard-deletes of
> compositions and Ehrs. This is a complex area as GDPR does not confer an
> absolute right for medical info to be forgotten (as I understand it). It
> does allow for copies of the record to be retained for medico-legal
> purposes.
>
> However, in our cloud-provider setting, we absolutely need to be able to
> hard delete Ehrs, as people may simply want to switch CDR providers. As a
> data processor, we have no right to keep t record, as long as it is
> available via another provider.
>
> Ian
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859 <+44%207752%20097859>
> office +44 (0)1536 414994 <+44%201536%20414994>
> 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 Sat, 1 Sep 2018 at 14:52, Bert Verhees  wrote:
>
>> OpenEhr does not really allow to delete data, only logical deletion (mark
>> as deleted), but GDPR demands the right of the patient to be forgotten.
>>
>> Is there some change expected in the specs for compliance to GDPR, or was
>> this already implemented?
>>
>> We had this discussion, slightly different, about ten months ago but no
>> conclusion if I recall well
>>
>> Sorry if I missed a message about this.
>>
>> Thanks
>> Bert Verhees
>>
> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Holistic view, was :AQL on specific list of compositions

2018-09-01 Thread Bert Verhees

Contsys will update some definitions. They are now the base of their thinking, 
but I am sure that will change soon. 

Thanks, Gérard, for giving me the opportunity to make my point again. :-) 

We don't call war a peace problem. So why do we call illness a health problem? 

Normally I would not mention such a small thing. But the positive naming could 
be standing in the way of a more holistic view. Healthcare is now about 
care-for illness. Medicine is not always about healing. It are medieval 
understandings in the way we still use them. 

Healthcare must also be for healthy people 

For example, food is important, not only for people with a disease, but also 
for healthy people so that they do not get a disease. 

According businessplans of tech giants, like Google, Amazon, etc,  a PHR will 
contain a holistic view of the consumer (not patient). The PHR will contain 
data from sport, leisure, diseases, yoga, food, everything related to health. 
Not only the negative aspects, but all aspects. This change in philosophy of 
healthcare is taking place quite some time now, but now reaching the upper 
levels of society. 

Preventing diseases will become a major way of spending healthcare money. If 
insurance companies can keep their members healthy, they are saving money. 

If companies do not start to change, they will lose their position on the 
billion dollar market. 
There will be a new business-competition. The patient will become a consumer 
and will give new meaning to the word healthcare. 

Change starts with using words in another way.

Now is the time to start with this. The world is changing fast, and we will 
change with it. 

Verzonden vanaf mijn Xperia™ van Sony-smartphone

 GF schreef 

>HI Ian,
>
>Some definitions from Consys
>These are taken from: https://contsys.org
>
>problem: health condition  
>considered by a healthcare actor 
> to be a problem
>health problemlist:health thread  
>linking a set of health problems 
>health issue: representation of an issue related to the health 
> of a subject of care 
> as identified by one or more 
>healthcare actors 
>episode of care: health related period 
> during which healthcare 
>activities  are performed to 
>address one health issue  as 
>identified by one healthcare  
>professional[
>
>
>
>Gerard   Freriks
>+31 620347088
>  gf...@luna.nl
>
>Kattensingel  20
>2801 CA Gouda
>the Netherlands
>
>> On 20 Aug 2018, at 11:13, Ian McNicoll  wrote:
>> 
>> @Gerard - I have always assumed that Contsys 'Health Issue' equates to 
>> problem.
>> 
>> https://github.com/openehr-clinical/shn-contsys 
>> 
>> 
>> Ian
>> 
>
>
>___
>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: GDPR and OpenEhr.

2018-09-01 Thread Bert Verhees

There are good arguments in the discussion. I take this message to reply to 
because it is the last for this subject at the moment. 

I am thinking of following situation. This week, Microsoft, Google, Amazon and 
IBM agreed that there must be a health data platform which exposes itself in 
FHIR and API. Apple will certainly connect too. What will run below is not 
specified. It could well be OpenEhr. Their might also be smaller parties which 
will be health data provider. 

The idea is that the patient (or better, consumer) becomes the owner of the 
data. A connected PHR. He gives the healthcare providers access to his data.  
The healthcare data company is a tech company and the consumer choose it like 
he chooses his telephone provider.. Maybe it is a combined service. 

GDPR supports this new market idea. But when the user switches provider, he 
must be sure that all his data are removed from the old provider. 

This is the intention from the tech companies, and it is a good intention.  

Of course the Google's of this earth will be leading, but it is an open market 
so small parties can also enter and compete on price or special features in 
context of mhealth or sport-support or support for special conditions. 

Anyway, I have read about this this week in a journal, and it seems very 
promising. That was my thought about asking. 

I am now writing this from my phone, but tomorrow after 1200 km driving, I can 
come back to this. 

Best regards
Bert

Verzonden vanaf mijn Xperia™ van Sony-smartphone

 Karsten Hilbert schreef 

>On Sat, Sep 01, 2018 at 08:33:08PM +0200, Diego Boscá wrote:
>
>> Supporting hard delete doesn't mean mandate hard delete :)
>
>Indeed. I agree with that.
>
>Karsten
>-- 
>GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
>
>___
>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

GDPR and OpenEhr.

2018-09-01 Thread Bert Verhees

OpenEhr does not really allow to delete data, only logical deletion (mark as 
deleted), but GDPR demands the right of the patient to be forgotten.

Is there some change expected in the specs for compliance to GDPR, or was this 
already implemented? 

We had this discussion, slightly different, about ten months ago but no 
conclusion if I recall well

Sorry if I missed a message about this. 

Thanks
Bert Verhees___
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

2018-08-21 Thread Bert Verhees

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

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

<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

<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


--
Sebastian Iancu
mob: +31625588176 | email:sebast...@code24.nl  
Code24 B.V.

Comeniusstraat 2d, 1817MS Alkmaar, The Netherlands
www.code24.nl


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



--
*Bert Verhees*
Software developer, architect
Twitter: https://twitter.com/VerheesBert
LinkedIn: https://www.linkedin.com/in/bertverhees/
Email: bert.verh...@rosa.nl <mailto:bert.verh...@rosa.nl>
Mobile: +31 06 28050294
___
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

2018-08-18 Thread Bert Verhees

As far as I understand, and I also implemented it like that, there should never 
be functionality to delete data. Accidental deletion can only occur when you 
pass the software and hack on the database directly. That should never occur 
and if it does, the database should be restored to a safe point in the backup 
routine. 

A folder is a versioned immutable object, that can never be changed or deleted, 
according the specs, or did I miss a change? 

Sorry in that case for my speaking while not being up to date. I don't read the 
specs every day. 

Bert 

Verzonden vanaf mijn Xperia™ van Sony-smartphone

 Seref Arikan schreef 

>My point was more about querying aspects. Tom emphasized data integrity
>aspects.
>
>I think we've survived just fine so far without any mechanisms similar to
>foreign keys in relational dbs that would stop a folder from being deleted,
>so I'd say go with folders as you intend to.
>
>My concerns can (probably) be handled by smarter Aql down the line.
>
>On Saturday, August 18, 2018, Dileep V S  wrote:
>
>> Very interesting discussion that has helped us get some of our thoughts
>> clarified. We have started building a virtual folder as a service outside
>> Ethercis to cover our requirements and are hoping to migrate the structure
>> into the EHR server at a later date.
>>
>> The plan is to cover both the things mentioned in Thomas's response. We
>> intend to get a list of compositions associated with a folder from this
>> service and pass it to the AQL to get what we want.
>>
>> However, I am not sure how to rebuild the folder structure if it is lost.
>> We do not have any folder related information inside Compositions and so
>> the query can only go from folder to the composition and not the other way.
>> Keeping folder details in Composition may not be a good idea as folder is
>> meant to be virtual grouping and can have some dynamism around it. Also
>> same composition can, in theory, be part of multiple folders. There is also
>> the concept of a folder hierarchy that exists only within the folder
>> service.
>>
>> regards
>>
>> Dileep V S
>> *Founder*
>> HealtheLife Ventures LLP
>> m: +91 9632888113
>> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
>> w: healthelife.in  e: dil...@healthelife.in
>>
>> On Fri, Aug 17, 2018 at 9:30 PM, Thomas Beale 
>> wrote:
>>
>>>
>>> The easiest way to think about this question is: if someone trashed the
>>> Folder structure, could we (some admin app) rebuild it? The answer is
>>> interesting. It should normally be possible to rebuild the Folder /
>>> Composition association structure (it's not containment, just referencing),
>>> but of course, if you stored other information in the Folders, for example
>>> in the recently SEC-approved other_details structure, then you would lose
>>> that.
>>>
>>> So the Folder approach does two things:
>>>
>>>- represents a pre-built query result (the Folder/Composition
>>>associations) - giving instant access, and avoiding having to construct 
>>> the
>>>query, which is usually somewhat messy.
>>>- allows other information to be stored directly about the thing the
>>>Folder represents, e.g. admission / stay in a facility.
>>>
>>> - thomas
>>>
>>> On 17/08/2018 16:20, Seref Arikan wrote:
>>>
>>> Hi Ian,
>>>
>>> When the fact that the Composition is associated to an encounter or
>>> episode of care is recorded by including a reference to that composition in
>>> a folder, some clinical context/information related to that composition is
>>> now stored outside the composition, by means of a refence in a folder
>>>
>>> Unless I'm missing an Aql feature that can help, you can no longer select
>>> those compositions via Aql (since Aql does not support/specify how to
>>> resolve refs)
>>>
>>> If you follow the encounter id approach you mentioned, then you could use
>>> Aql.
>>>
>>> In fact, if Ethercis had support for Folder, Dileep would still not be
>>> able to get those compositions with a singl query: he'd need to fetchs uids
>>> from a folder with one query, then perform a second query to get
>>> compositions in the way I suggested.
>>>
>>> I'm probably being unnecessarily picky here, just pointing at the
>>> difference between approaches and trying to put my finger on any downstream
>>> issues. I'm not doing a great job of it though :)
>>>
>>> On Friday, August 17, 2018, Ian McNicoll  wrote:
>>>
 Hi Seref,

 I'm not sure I understand your concerns here. I think the use case is
 where there is a need to group compositions by some other higher level
 construct which usually reflect something like an admission, episode of
 outpatient care or perhaps a community plan of care.

 As Dileep has indicated he probably would use folders if Ethercis
 supported them. Another alternative is to create an Encounter ID for each
 new encounter (which in Dileep's example, I think I would call an episode
 of care, and simply tag each

Re: AQL on specific list of compositions

2018-08-18 Thread Bert Verhees

I cannot imagine how a folder structure can get lost except by data
corruption. In that case anything is lost anyway and a rollback from a
backup is needed.

In fact there should not be a folderstructure in the database. There are
folder objects which contain a list of references (data) to compositions.
Not the compositions itself are in those lists. That would not be possible
because a composition can be referenced in more then one folder.

But maybe I am missing something

Bert

Op za 18 aug. 2018 05:40 schreef Dileep V S :

> Very interesting discussion that has helped us get some of our thoughts
> clarified. We have started building a virtual folder as a service outside
> Ethercis to cover our requirements and are hoping to migrate the structure
> into the EHR server at a later date.
>
> The plan is to cover both the things mentioned in Thomas's response. We
> intend to get a list of compositions associated with a folder from this
> service and pass it to the AQL to get what we want.
>
> However, I am not sure how to rebuild the folder structure if it is lost.
> We do not have any folder related information inside Compositions and so
> the query can only go from folder to the composition and not the other way.
> Keeping folder details in Composition may not be a good idea as folder is
> meant to be virtual grouping and can have some dynamism around it. Also
> same composition can, in theory, be part of multiple folders. There is also
> the concept of a folder hierarchy that exists only within the folder
> service.
>
> regards
>
> Dileep V S
> *Founder*
> HealtheLife Ventures LLP
> m: +91 9632888113
> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
> w: healthelife.in  e: dil...@healthelife.in
>
> On Fri, Aug 17, 2018 at 9:30 PM, Thomas Beale 
> wrote:
>
>>
>> The easiest way to think about this question is: if someone trashed the
>> Folder structure, could we (some admin app) rebuild it? The answer is
>> interesting. It should normally be possible to rebuild the Folder /
>> Composition association structure (it's not containment, just referencing),
>> but of course, if you stored other information in the Folders, for example
>> in the recently SEC-approved other_details structure, then you would lose
>> that.
>>
>> So the Folder approach does two things:
>>
>>- represents a pre-built query result (the Folder/Composition
>>associations) - giving instant access, and avoiding having to construct 
>> the
>>query, which is usually somewhat messy.
>>- allows other information to be stored directly about the thing the
>>Folder represents, e.g. admission / stay in a facility.
>>
>> - thomas
>>
>> On 17/08/2018 16:20, Seref Arikan wrote:
>>
>> Hi Ian,
>>
>> When the fact that the Composition is associated to an encounter or
>> episode of care is recorded by including a reference to that composition in
>> a folder, some clinical context/information related to that composition is
>> now stored outside the composition, by means of a refence in a folder
>>
>> Unless I'm missing an Aql feature that can help, you can no longer select
>> those compositions via Aql (since Aql does not support/specify how to
>> resolve refs)
>>
>> If you follow the encounter id approach you mentioned, then you could use
>> Aql.
>>
>> In fact, if Ethercis had support for Folder, Dileep would still not be
>> able to get those compositions with a singl query: he'd need to fetchs uids
>> from a folder with one query, then perform a second query to get
>> compositions in the way I suggested.
>>
>> I'm probably being unnecessarily picky here, just pointing at the
>> difference between approaches and trying to put my finger on any downstream
>> issues. I'm not doing a great job of it though :)
>>
>> On Friday, August 17, 2018, Ian McNicoll  wrote:
>>
>>> Hi Seref,
>>>
>>> I'm not sure I understand your concerns here. I think the use case is
>>> where there is a need to group compositions by some other higher level
>>> construct which usually reflect something like an admission, episode of
>>> outpatient care or perhaps a community plan of care.
>>>
>>> As Dileep has indicated he probably would use folders if Ethercis
>>> supported them. Another alternative is to create an Encounter ID for each
>>> new encounter (which in Dileep's example, I think I would call an episode
>>> of care, and simply tag each composition with that Encounter ID e.g create
>>> a cluster archetype to hold this in every Composition/ other_context. I
>>> have done that on other projects. So it is a case of looking of all
>>> composition with EncounterId = x
>>> Now I would probably go down the Folder route, if I could.
>>> 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
>>>

Re: Empty COMPOSITION.content is valid?

2018-07-26 Thread Bert Verhees


On 26-07-18 09:57, Thomas Beale wrote:

Does it make sense to have an empty COMPOSITION.content?


Imagine a visit to a GP, and nothing clinical comes out of it. Nothing 
worth mentioning, but still having had a composition and a consult to 
pay for.



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

Re: UCUM/SNOMED/custom units

2018-07-23 Thread Bert Verhees


On 23-07-18 13:45, Diego Boscá wrote:
Units need to be (and will be) revamped, we also need other things 
already discussed in other posts like rubric, long descriptions (which 
could be language dependent), etc. This could be very useful for 
better describing custom UCUM units too.
Several alternatives are being explored in order to not break current 
units definitions. Maybe adding an optional codephrase or terminology 
mapping could do the trick, as then you can tell where the unit comes 
from and allows you to provide a "code" which could either contain a 
Snomed code or a UCUM expression. Inputs are appreciated as always :)


I think your suggested solution is just right ;-)
But possible I do not oversee all consequences

Bert

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

UCUM/SNOMED/custom units

2018-07-23 Thread Bert Verhees

I wonder if it is possible to use other units then UCUM units in 
DV_QUANTITY. I read from Pablo in Stackoverflow that the SEC is 
considering custom units. I think this is great, but I see some problems 
coming up. I have some questions about this,


I wonder how you can do that without changing the 
DV_QUANTITY-definition, because it has a units-attribute, it says it 
must be expressed in UCUM syntax. It does not say anything about the 
unit itself, only about the notation.


Must we understand UCUM so, that it has not only a syntax for its own 
units, but also for custom units?


That is strange, because custom-units (non-UCUM) can carry custom 
(non-UCUM) syntax-descriptions. So if we are writing a custom unit, and 
using a syntax to specify it, then we need two references, don't we?


One reference for where the unit comes from, and one reference for the 
syntax?



A custom unit can also occur in another standard, for example SNOMED, 
also a UCUM-unit can occur in SNOMED, but is it sure it means the same? 
Normally we are very prudent about things like this.
I found a HL7 wiki about this. Someone did some thinking about this. I 
think that also applies to OpenEhr.


http://wiki.hl7.org/index.php?title=Representation_of_Units

Best regards
Bert Verhees

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

Re: Meaningful API's


On 17-07-18 12:15, Thomas Beale wrote:
One general thing to remember is that there will normally be multiple 
levels of API, from data to domain to business to application. 


Agree, good to list the levels.

Bert


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

Re: Meaningful API's


On 17-07-18 12:05, Ian McNicoll wrote:

This is harder for newbies to understand but


We don't write API's as learning material for newbies, but for 
professional communication, so that is no problem.


Also for the rest I agree.

There is need for API's for interaction between two OpenEhr 
environments, and API's for the rest of communications (that will be 
used most). I mentioned FHIR as example, of course FHIR is not perfect. 
But we cannot deny its success.


A specific message-format-API is not what I am looking for, by combining 
several API's, a developer should be able to craft any message he wants, 
very easy. I have done that a lot, also last year. It is sometimes my 
daily income.


Often we forget that on discussion-lists we are in the year 2525, but on 
the market we still see message types from 20 years ago, HL7v2, EDIFACT, 
XML, vendor specific formats, it all happens a lot. Sometimes the only 
way to communicate with some critical software-products.




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

Re: Meaningful API's


On 16-07-18 16:59, Thomas Beale wrote:
well whether it is 'so good' is in the eye of the beholder, but it is 
'good enough' for quite a lot of things, things for which we would 
once have expected to be able to use XMI. Anyway, the BMM introduction 
 
provides some information on why it is there.


BMM does not serve the purpose of describing API's. It serves the 
describing of software models.


API's are communication-protocols. You can compare them with network 
protocols. There can be structures in them, and there are, in JSON, also 
in protobufs.


But these structures do not serve the purpose of building an application 
around it. They only serve to communicate data. The receiving party must 
be able to recognize the structure, but the receiving side does not need 
to know that a list of structures is of a generic type. It will find out 
when reading the message that all the components of a list are from a 
specific type (if it is interested). Maybe for the receiving side, the 
fact that a specific list has generic data-items is not important, 
because in its own universe this is different. The same counts for 
hierarchy/inheritance. The receiving side does not need to know that a 
structure in message A is inherited from a structure in message B.


The receiving side probably will tear apart the structures and reorder 
the data in its own structures.


So any API design method which handles generics and inheritance 
communicates a lot of useless information, unless the other side is 
exactly the same machine, then they have a common center of the 
universe. However, this should never be the purpose of an API, nor the 
purpose of a message.


The strong point of FHIR (where its success comes from) is that every 
application can understand it. For this reason, I think that OpenAPI 
will suffice for the purpose.


Bert

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

Re: Meaningful API's

On 16-07-18 16:54, Ian McNicoll wrote:

Hi Bert,

Have a look at what Ripple is doing in terms of 'meaningful APIs'.

See
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2018-February/014799.html

This is interesting, although, what I understand from it in a "quicky"
This is what I think to have read in that quick information absorption.

In the link is (I think) explained that one should not build a GUI
around a datamodel, but have their own criteria to build a GUI.
I agree with that, because a GUI serves another purpose then a datamodel
(in which the data are stored)
The same is also for creating a message, it must not mimic the datamodel
where it comes from, but have its own criteria, based on
understandability and structures for others also easy to follow in
receiving and transmitting.

Unless you are the center of the universe, of course, then you can
expect others to follow you, that they have the functionality to
understand and parse what you bring over.

This is interesting because this means that an API does not need to
export OpenEhr/archetype-structures, they are often not going to be used
anyway.
So that is not what we want, as a study from Helma van der Linden
apparently also shows.
A GUI, a message, (an API) should be effective in the context of the
receiver, not in the context of the sending party.

Thomas called the medication API from the Human API "low level", but
this was a confusing term. Better would have been to call it primitive,
or something like that. But what he meant to say was understandable and
right in that example. But I like to rephrase it because it better fits
in my thinking. (funny, this communication misunderstanding is a lot
like API misunderstandings, so context is important.)

Low level in OpenEhr context would mean, exporting the structures as
they are found inside OpenEhr-storage, Low level would mean in my
understanding, as close as possible to the source. Mostly, low level is
more complicated then high level. Compare it with ways of communicating
computer-instructions: assembly (Low Level, complex, processor-type
bounded and not fit or interoperability) with Java (High level, not
complex, runs on every machine).

That is what an API does. It does not want to preserve structures which
are in use on the sending side, but it wants to exchange data with other
purposes/platforms in a way that it is easy to understand. We cannot
expect from the other side that they know how to parse archetypes.

So we could ask ourselves, is "more primitive" worse then "low level"?
There must be a level between these which is good.
I agree that meta-data, like "created at", "id" should not be mixed up
with clinical data. So that part is not right in the Human API
medication call. Maybe there are more points wrong.
But that should not be the discussion. The discussion should be about
how the API will look like, (and maybe learn from others, because others
will use the API)

And there is another thing, an API should be stable. Because CKM is
regarded as a base-structure set for OpenEhr which is sensible to use,
this does not mean that every OpenEhr installation follows CKM
completely, partly, or not at all. This is propagated as flexibility.
CKM is not the center of the universe. An API should therefor not impose
a structure from CKM on users. It should have its own means of
communication. This must consist from primitive structures, because many
software designers which think in other ways must find it usable.

Apart from this interoperability (with other paradigms) thinking, there
can of course also be a low level API which dumps archetype structures
over the wall because the other side knows how to parse ADL and knows
how to store and retrieve archetyped data, so the other side is an
OpenEhr machine. Between two OpenEhr systems, OpenEhr is the center of
the universe.

Best regard
Bert Verhees

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 Mon, 16 Jul 2018 at 15:06, Bert Verhees <mailto:bert.verh...@rosa.nl>> wrote:

On 16-07-18 15:56, Bert Verhees wrote:
> But again, the starting point must be the API's defined, maybe in a
> transformerable language like swagger, which seems to connect
well to
> the OpenAPI initiative.(I never liked swagger much, but my last
> experience with it was from years ago, maybe it is better now)
>
> And then you mentioned BMM, I don't know about that. I should
look at
> it, I saw your other email. Do you have

Re: Meaningful API's


On 16-07-18 16:54, Ian McNicoll wrote:

Hi Bert,

Have a look at what Ripple is doing in terms of 'meaningful APIs'.

See 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2018-February/014799.html

I check it, thanks for the info
Bert

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

Re: Meaningful API's


On 16-07-18 16:59, Thomas Beale wrote:
well whether it is 'so good' is in the eye of the beholder, but it is 
'good enough' for quite a lot of things, things for which we would 
once have expected to be able to use XMI. Anyway, the BMM introduction 
 
provides some information on why it is there.


XMI is not designed to describe functions, but it is an 
object-description language, and very limited indeed. And still used and 
illegally extended, and therefor not fit for exchange of models.


I read the BMM introduction. Thanks for the link.

Bert

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

Re: Meaningful API's


On 16-07-18 15:56, Bert Verhees wrote:
But again, the starting point must be the API's defined, maybe in a 
transformerable language like swagger, which seems to connect well to 
the OpenAPI initiative.(I never liked swagger much, but my last 
experience with it was from years ago, maybe it is better now)


And then you mentioned BMM, I don't know about that. I should look at 
it, I saw your other email. Do you have somewhere a document why BMM 
is so good?


The latest version of Open API (swagger became the Open API)

https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.1.md


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

Re: Meaningful API's


On 16-07-18 14:55, Thomas Beale wrote:




On 16/07/2018 13:35, Bert Verhees wrote:

On 16-07-18 13:49, Thomas Beale wrote:
It seems to be a competitor to FHIR in some way, since it is not 
using FHIR.

Aren't we all? ;-)

But serious, I don't think so, they don't use FHIR because their 
target-market does not use FHIR. It are mostly REST-webservices they 
have as target, they combine and convert the API's to their own API.


https://www.humanapi.co/data-network

Not the company, but their API was meant as an example.

I just had a look at this. It's pretty low-level. See Medications 
API <https://reference.humanapi.co/#medications> for example.
Depends on what you call low level. In this discussion, yesterday, I 
called the OpenEhr API low-level, because it had no meaningful API's 
at all. So calling this also low-level might be confusing.


They return with medication, productname, brandname, dosageinfo, 
pharmacy, generic productname, I don't understand why you think this 
is low level.




It was not particularly meant as a criticism, but have a look at this:



We can see that:

  * there is no structuring - it's a flat list
  * there are only basic programming types (probably from TypeScript)
  * there is a mixture of infrastructure / data management and content
fields (the former highlighted).

Maybe this is fine for some uses, maybe many. But if you look at the 
CKM or Apperta or other medication archetypes, it's easy to see that 
obtaining that kind of data would be somewhat painful with this 
interface. An interface of similar simplicity, but /generated/ from 
templates using those archetypes however would be interesting...
When I said, that API is an example I meant the data they were able to 
transmit, not the structure. It is not surprising that they use 
typescript-like data, it is a REST based API, and typescript is the 
better kind of Javascript, it also fits good on JSON. When looking at 
the data they represent, I thought, it would be a good example of what a 
basic API should be able to. So just an example. I explained that in the 
first email of this thread with this subject.


The first is to generate APIs from templates, in the same way we 
generate a TDS (Template Data Schema, which is an XSD) from a 
template. All we need to do to build a transformer, not hand-build 
APIs (that's last century thinking). This means we would have a way 
to generate an API from any template, i.e. any content. This kind of 
API is one way to get data out of a system


There are also many tools, also for many purposes, mostly all in 
their own programming language eco-system. You are jumping to the 
technical process already. That is nice. Where can we download the 
templates you are talking about. And what should be the target of the 
transformer, or multiple-targets?




well some templates are being slowly added to the international CKM 
and other CKMs, but generally, templates are what local users and 
vendors create themselves. Since they don't break archetypes, it is 
safe to create them according to your own data-set needs.
That is true, but isn't the same true for AQL? AQL is able to do things 
which templates are not so well designed for, like scanning over 
datasets of more patients in a single query. Maybe both, templates and 
AQL are necessary/usable.


But again, the starting point must be the API's defined, maybe in a 
transformerable language like swagger, which seems to connect well to 
the OpenAPI initiative.(I never liked swagger much, but my last 
experience with it was from years ago, maybe it is better now)


And then you mentioned BMM, I don't know about that. I should look at 
it, I saw your other email. Do you have somewhere a document why BMM is 
so good?


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

Re: Machine Learning , some thoughts

2018-06-30 Thread Bert Verhees


On 30-06-18 10:46, Thomas Beale wrote:



I would have thought the easiest way would be to machine convert the 
RM BMM 
 
and the Abstract Platform UML model 
 
to the protobuf3 specification format. Note that when reading the BMM 
files it is better to use existing tools or libraries to read them in 
and convert the multiple files to a single model - this is what you 
see in the ADL Workbench, and the new Archie project 
 does this a well.




That is good, I look at the code, and see how it is done. Reading the 
model should not be a problem then. When I have questions, I let you and 
Pieter Bos  on this list.


I think what would be most interesting is to develop a repeatable 
mechanism / tool to do this.



Exactly my idea.

This would get us a generic protobuf3 service interface that 
implements the Abstract Platform model.


If you wanted to have a more specialised service interface based on 
particular archetypes or templates (I would have thought the latter), 
then it seems to me that you want to generate template structures as 
specialisations of their corresponding RM types. protobuf3 format 
 
doesn't know about specialisation, so we would need to work out a way 
to represent it, but this has to be a standard problem.




I have written a proto-file for ucum, because I have written an 
ucum-micro-service. I do not have that open source (yet) but showing a 
part of the proto file does not hurt.


Regarding to class hierarchy, when in the way, I take the widest class 
which can have all possible attributes and add an enum to indicate which 
class was meant.
(I call it "flattened", and put the word Derivates to the end, which, on 
second thought, would not have been necessary, all derivates of the Ucum 
Concept-class fit in this construct)


message FlattenedConcepterDerivates {
string Code =1;
string CodeUC =2;
enum ConceptKind {
PREFIX =0;
BASEUNIT =1;
UNIT =2;
}
ConceptKind Kind =3;
repeated string Names =4;
string PrintSymbol =5;
string Property =6;
string Class =7;
bool IsSpecial =8;
bool Metric =9;
bool IsArbitrary =10;
string Dim =11;
Value Value =12;
}


This works good, because the only purpose is to bring over the data and 
reproduce them again to the original state as they were send.
It only needs to read the attributes which belong to the class indicated 
in the enum.
In this way, the optimal use of the protobuf principle is used (having 
everything in its own primitive datatype, and only read/write to the 
buffer what is necessary).

But maybe there is a better way?

Note that in protobuf3 you can specify a message definition and a 
service definition. This would enable the machine generation of 
message definitions corresponding to any openEHR data - i.e. the 
protobuf equivalent of Template Date Schema (TDS).
I am not sure what you mean here. Maybe it gets clear when I read the 
code from Pieter.
In my current point of view in protobuf, the service-part represents the 
functions (compare them with API-calls in REST), and the message parts 
are the data.
This is how the service and message part look like. Some messages 
represent classes out of the application-sphere (as seen in the previous 
example), some represent data used as parameter-sets (I call them 
Request and Response messages). I copy some example-lines from the 
ucum-service-proto below.


syntax="proto3";

package ucum_service;

service UcumService{
rpc UcumIdentification(UcumVersionDetailsRequest) returns 
(UcumVersionDetailsResponse){};
rpc ValidateUCUM(ValidateUCUMRequest) returns (ValidateUCUMResponse){};
rpc Search(SearchRequest) returns (SearchResponse){};
rpc GetProperties(GetPropertiesRequest) returns (GetPropertiesResponse){};
...
...
}

message UcumVersionDetailsRequest {
}

message UcumVersionDetailsResponse {
int64 releaseDate =1;
string version =2;
}

message ValidateUCUMRequest {
}

message ValidateUCUMResponse {
repeated string serviceStatus =1;
}

message SearchRequest {
enum ConceptKind {
PREFIX =0;
BASEUNIT =1;
UNIT =2;
}
ConceptKind Kind =1;
string text =2;
bool isRegex =3;
}

message SearchResponse {
repeated FlattenedConcepterDerivates results =1;
}





Best regards
Bert

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

Re: Machine Learning , some thoughts

2018-06-29 Thread Bert Verhees


On 29-06-18 10:27, Thomas Beale wrote:



The intention is certainly a good one. It just needs to be the 
reference model and the Abstract Platform Specification 
<http://www.openehr.org/releases/SM/latest/openehr_platform.html> as 
the starting point.



I was thinking of the following.

We can "translate" the core-RM (which is to use in archetypes) to 
protocol-buffers definitions. These protocol buffer definitions are 
programming language independent. It should be possible to convert the 
definitions (in XML I believe?) directly to this format (with a small 
application).


Is this still maintained, or is there something else I should use? I 
could write such a small application. Would take me a few days when 
doing it in spare time.

https://github.com/openEHR/specifications-ITS/tree/master/RM/XML-schema

This would be a good start. Next task would be a small application which 
"translates" archetypes to protocol buffers.
I was thinking this afternoon how that could be done, because archetypes 
are flexible to use, you don't want any archetype-code in the kernel.
But on the other hand, protocol buffers demand compiled protocol buffer 
definitions. So archetypes will then be compiled for the sake of network 
traffic.
This compiled code could have standard API calls to ask which archetype 
it represents.


I don't know how the feelings are about this.

Bert



- thomas


On 28/06/2018 16:25, Bert Verhees wrote:

On 28-06-18 17:19, Bert Verhees wrote:
Never use REST/JSON/HTTP1.1 for stable models, it is throwing away a 
lot of performance.


How about creating a protocol-buffer generation tool for archetypes, 
or as a matter of fact, for the reference model would be sufficient.

Good idea, to remember.

Or has someone already done it and did I miss it?

Bert




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


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



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



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

Re: Machine Learning , some thoughts

2018-06-28 Thread Bert Verhees


On 28-06-18 17:19, Bert Verhees wrote:
Never use REST/JSON/HTTP1.1 for stable models, it is throwing away a 
lot of performance.


How about creating a protocol-buffer generation tool for archetypes, or 
as a matter of fact, for the reference model would be sufficient.

Good idea, to remember.

Or has someone already done it and did I miss it?

Bert


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

Re: SMART on FHIR integration

2018-04-24 Thread Bert Verhees


sorry for the sloppy text, a bit in a hurry ;-)

On 24-04-18 10:34, Bert Verhees wrote:
Maybe it is interesting to facilitate a SMART API for OpenEhr (now 
there is an API-definition effort in process for OpenEhr)?
Or is that to market specific and is it something more suitable for 
vendors or other third parties to develop?


That reminds me of an other discussion which runs for years. The 
status of the demographic-RM. To make OpenEhr suitable for consumer 
market-segments, it needs a full demographic section and API. I don't 
know if that was talked about in the latest SEC meetings, but the 
healthICT market is coming out of the hospitals and is going from 
professional healthcare, but also consumer/customer healthcare, and 
there is often no external demographic service except only based on 
OAuth, which has another reliability characteristic.


So, summarizing, healthICT is shifting from healthcare professionals 
to consumers. Does this need adaptations from the OpenEhr side, 
especially in the coming API?


Bert

On 24-04-18 02:23, michael.law...@csiro.au wrote:



The real value of SMART (whether its "on FHIR" or not) is that it 
sets a mechanism for EMRs to pass context to external apps.  This 
means apps are re-usable across different back ends.



Note that this is not really about authentication (SSO) but rather it 
is about authorisation.



michael


--
Dr Michael Lawley
Research Group Leader, Health Informatics
The Australia e-Health Research Centre http://aehrc.com/
work: +61 7 3253 3609; mob: +61 427 456 260

*From:* openEHR-technical 
<openehr-technical-boun...@lists.openehr.org> on behalf of Pablo 
Pazos <pablo.pa...@cabolabs.com>

*Sent:* Tuesday, 24 April 2018 9:29 AM
*To:* For openEHR technical discussions
*Subject:* Re: SMART on FHIR integration
SSO is a front end feature, that is not on the current scope of the 
openEHR specs.


I think any openEHR implementer can do SSO at the front-end app level 
to access SMART apps.


On Mon, Apr 23, 2018 at 6:14 PM, Brian Nantz <br...@nantz.org 
<mailto:br...@nantz.org>> wrote:


I see you have had discussions on FHIR and SMART on FHIR.  Is it
on the roadmap for openEHR to support SMART on FHIR launch
sequence (http://docs.smarthealthit.org/authorization/
<http://docs.smarthealthit.org/authorization/>) for single sign
on?  I know many customers who would like this seemless integration.

___
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

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




--
Ing. Pablo Pazos Gutiérrez
pablo.pa...@cabolabs.com <mailto:pablo.pa...@cabolabs.com>
+598 99 043 145
skype: cabolabs
<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
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: SMART on FHIR integration

2018-04-24 Thread Bert Verhees

Maybe it is interesting to facilitate a SMART API for OpenEhr (now there 
is an API-definition effort in process for OpenEhr)?
Or is that to market specific and is it something more suitable for 
vendors or other third parties to develop?


That reminds me of an other discussion which runs for years. The status 
of the demographic-RM. To make OpenEhr suitable for consumer 
market-segments, it needs a full demographic section and API. I don't 
know if that was talked about in the latest SEC meetings, but the 
healthICT market is coming out of the hospitals and is going from 
professional healthcare, but also consumer/customer healthcare, and 
there is often no external demographic service except only based on 
OAuth, which has another reliability characteristic.


So, summarizing, healthICT is shifting from healthcare professionals to 
consumers. Does this need adaptations from the OpenEhr side, especially 
in the coming API?


Bert

On 24-04-18 02:23, michael.law...@csiro.au wrote:



The real value of SMART (whether its "on FHIR" or not) is that it sets 
a mechanism for EMRs to pass context to external apps.  This means 
apps are re-usable across different back ends.



Note that this is not really about authentication (SSO) but rather it 
is about authorisation.



michael


--
Dr Michael Lawley
Research Group Leader, Health Informatics
The Australia e-Health Research Centre http://aehrc.com/
work: +61 7 3253 3609; mob: +61 427 456 260

*From:* openEHR-technical 
 on behalf of Pablo Pazos 


*Sent:* Tuesday, 24 April 2018 9:29 AM
*To:* For openEHR technical discussions
*Subject:* Re: SMART on FHIR integration
SSO is a front end feature, that is not on the current scope of the 
openEHR specs.


I think any openEHR implementer can do SSO at the front-end app level 
to access SMART apps.


On Mon, Apr 23, 2018 at 6:14 PM, Brian Nantz > wrote:


I see you have had discussions on FHIR and SMART on FHIR.  Is it
on the roadmap for openEHR to support SMART on FHIR launch
sequence (http://docs.smarthealthit.org/authorization/
) for single sign
on?  I know many customers who would like this seemless integration.

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


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






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

http://www.cabolabs.com 
https://cloudehrserver.com 
Subscribe to our newsletter 



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

That is the problem. There is no focus. This discussion will not solve
anything.



Op di 3 apr. 2018 09:48 schreef GF <gf...@luna.nl>:

> It is Obvious:
>
> - We need to take the next step in Semantic Interoperability: Semantic
> interpretability.
> - And think about what is missing, so far
> - How to use codes from Terminologies and Classifications
> - How to deal with the full Context/Epistemology
> - How to deal with modifiers for presence/absence, certainty and other
> state info
> - What other models we need to deal with clinical, administration, and
> collaboration, processes
>
> In order to have systems that allow the full, safe, interpretation by
> humans, services, reasoners now and in the future.
> Systems with the minimal amount of implicit information needed to
> interpret safely and fully.
>
>
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 3 Apr 2018, at 09:35, A Verhees <bert.verh...@rosa.nl> wrote:
>
>
> GF :"There are NO agreed standardised archetypes/patterns we all use to
> define the meta-data in order to document the full eppistemology
>
>> so data can be interpreted fully and safely. "
>>
>
>
> So what do you suggest as a solution?
>
>
>
>
>>
>>
>>
>>
>>>
>>> Gerard   Freriks
>>> +31 620347088
>>>   gf...@luna.nl
>>>
>>> Kattensingel  20
>>> 2801 CA Gouda
>>> the Netherlands
>>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

Op di 3 apr. 2018 09:43 schreef GF <gf...@luna.nl>:

> Archetype modelling and the use of SNOMED pre- and/or post-coordination
>

You too have a nice day

>
>
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 3 Apr 2018, at 09:31, A Verhees <bert.verh...@rosa.nl> wrote:
>
> Can we specific define in about ten words which problem is talked about in
> this discussion?
>
> Maybe we can then use that definition as a guideline to keep the
> discussion focussed.
>
> Best regards
> Bert Verhees
>
> Op di 3 apr. 2018 01:19 schreef Pablo Pazos <pablo.pa...@cabolabs.com>:
>
>> Please see below,
>>
>> On Mon, Apr 2, 2018 at 6:17 PM, GF <gf...@luna.nl> wrote:
>>
>>> Is that so?
>>>
>>> There will be systems that allow pre-coordinated codes. There will be
>>> systems that use as many pre-coordinated codes. And several in between
>>> solutions.
>>>
>>
>> I agree, there will be systems that allow and use pre and post
>> coordinated codes, that is a fairly normal requirement in clinical
>> information systems and openEHR specs supports that.
>>
>>
>>> This means that reasoners will be used to create transformations.
>>>
>>
>> It doesn't mean that, I don't see where that is implied.
>>
>> Some systems might use reasoners using ontologies, rules, codes and other
>> content, to infer some "facts", and the results should be interpreted in
>> the same context as the ontologies, rules, clinical records and codes are
>> created, managed and used. Inferred facts are context dependent.
>>
>> Some other systems might not use any reasoners or ontologies at all, and
>> define programmatic rules that use SNOMED codes and expressions (pre and
>> post coordinated), and other contextual clinical / demographic /
>> administrative information to evaluate those rules and get some result (an
>> alert, a recommendation, a reminder, etc.)
>>
>> And other systems might not have rules at all and just use codes,
>> expressions and contextual data to create some visual representation of the
>> patient's status, to be presented to a clinician and make him/her evaluate
>> the data and make a decision. This is the most basic area we should cover,
>> and what originally generated this discussion: how to use SNOMED in openEHR
>> queries.
>>
>> Use cases are many, we can't focus on just one area and generalize from
>> there.
>>
>>
>>> It is likely that ontological servoces will be used, And then we will
>>> have a potential problem.
>>>
>>
>> That will really depend on specific implementations. I don't think
>> proposing a combination of standards with a lot of potential will cause any
>> issues per se.
>>
>>
>>
>>> But perhaps solvable with the correct precautions.
>>> One being that ontological servoces are NOT used and that ad hoc rules
>>> do the transform.
>>>
>>
>> That is exactly my point from above, automatic conclusions from a
>> reasoner or any AI can be interpreted as a general truth on any context.
>> Those conclusions should be interpreted in the same context as data and
>> knowledge was created. And semantics should be given by humans on a
>> per-context basis.
>>
>>
>>
>>> What possible solution is the canonical one? which is the ‘golden truth’.
>>>
>>
>> Since all that ^ is context-dependent, I don't think there is any
>> canonical form or golden truth.
>>
>>
>>>
>>> When we add to all this that only part of the epistemology can be
>>> pre-coordinated it means that part of the temporal aspects for instance can
>>> NOT be dealt with in SNOMED, then we have the situation that part of the
>>> epistemology is in SNOMED and part defined in the Archetype/Template.
>>>
>>
>> I agree and that is a good example of what I call "context" (how and
>> where knowledge and information is defined, managed and used, very related
>> to epistemology :)
>>
>>
>>>
>>>
>>> Gerard   Freriks
>>> +31 620347088 <+31%206%2020347088>
>>>   gf...@luna.nl
>>>
>>> Kattensingel  20
>>> 2801 CA Gouda
>>> the Netherlands
>>>
>>> On 2 Apr 2018, at 20:02, Pablo Pazos <pablo.pa...@cabolabs.com> wrote:
>>>
>>> Yes, but the main topic here is the use of SNOMED inside openEHR, so
>>> there is

Re: [Troll] Terminology bindings ... again

GF :"There are NO agreed standardised archetypes/patterns we all use to
define the meta-data in order to document the full eppistemology

> so data can be interpreted fully and safely. "
>


So what do you suggest as a solution?




>
>
>
>
>>
>> Gerard   Freriks
>> +31 620347088
>>   gf...@luna.nl
>>
>> Kattensingel  20
>> 2801 CA Gouda
>> the Netherlands
>>
>
> ___
> 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: [Troll] Terminology bindings ... again

Can we specific define in about ten words which problem is talked about in
this discussion?

Maybe we can then use that definition as a guideline to keep the discussion
focussed.

Best regards
Bert Verhees

Op di 3 apr. 2018 01:19 schreef Pablo Pazos <pablo.pa...@cabolabs.com>:

> Please see below,
>
> On Mon, Apr 2, 2018 at 6:17 PM, GF <gf...@luna.nl> wrote:
>
>> Is that so?
>>
>> There will be systems that allow pre-coordinated codes. There will be
>> systems that use as many pre-coordinated codes. And several in between
>> solutions.
>>
>
> I agree, there will be systems that allow and use pre and post coordinated
> codes, that is a fairly normal requirement in clinical information systems
> and openEHR specs supports that.
>
>
>> This means that reasoners will be used to create transformations.
>>
>
> It doesn't mean that, I don't see where that is implied.
>
> Some systems might use reasoners using ontologies, rules, codes and other
> content, to infer some "facts", and the results should be interpreted in
> the same context as the ontologies, rules, clinical records and codes are
> created, managed and used. Inferred facts are context dependent.
>
> Some other systems might not use any reasoners or ontologies at all, and
> define programmatic rules that use SNOMED codes and expressions (pre and
> post coordinated), and other contextual clinical / demographic /
> administrative information to evaluate those rules and get some result (an
> alert, a recommendation, a reminder, etc.)
>
> And other systems might not have rules at all and just use codes,
> expressions and contextual data to create some visual representation of the
> patient's status, to be presented to a clinician and make him/her evaluate
> the data and make a decision. This is the most basic area we should cover,
> and what originally generated this discussion: how to use SNOMED in openEHR
> queries.
>
> Use cases are many, we can't focus on just one area and generalize from
> there.
>
>
>> It is likely that ontological servoces will be used, And then we will
>> have a potential problem.
>>
>
> That will really depend on specific implementations. I don't think
> proposing a combination of standards with a lot of potential will cause any
> issues per se.
>
>
>
>> But perhaps solvable with the correct precautions.
>> One being that ontological servoces are NOT used and that ad hoc rules do
>> the transform.
>>
>
> That is exactly my point from above, automatic conclusions from a reasoner
> or any AI can be interpreted as a general truth on any context. Those
> conclusions should be interpreted in the same context as data and knowledge
> was created. And semantics should be given by humans on a per-context basis.
>
>
>
>> What possible solution is the canonical one? which is the ‘golden truth’.
>>
>
> Since all that ^ is context-dependent, I don't think there is any
> canonical form or golden truth.
>
>
>>
>> When we add to all this that only part of the epistemology can be
>> pre-coordinated it means that part of the temporal aspects for instance can
>> NOT be dealt with in SNOMED, then we have the situation that part of the
>> epistemology is in SNOMED and part defined in the Archetype/Template.
>>
>
> I agree and that is a good example of what I call "context" (how and where
> knowledge and information is defined, managed and used, very related to
> epistemology :)
>
>
>>
>>
>> Gerard   Freriks
>> +31 620347088 <+31%206%2020347088>
>>   gf...@luna.nl
>>
>> Kattensingel  20
>> 2801 CA Gouda
>> the Netherlands
>>
>> On 2 Apr 2018, at 20:02, Pablo Pazos <pablo.pa...@cabolabs.com> wrote:
>>
>> Yes, but the main topic here is the use of SNOMED inside openEHR, so
>> there is no terminology world separated from the content modeling and data
>> recording world. We will use SNOMED inside the openEHR context, so the
>> SNOMED meaning will be constrained by the openEHR meaning when recording
>> clinical information. We should be constraint to that context.
>>
>> On Mon, Apr 2, 2018 at 6:01 AM, GF <gf...@luna.nl> wrote:
>>
>>> Pablo,
>>>
>>> It is as Thomas and I wrote.
>>>
>>> *Open world Assumption:* Ontologies declare absolute truths
>>> irrespective of geographical location and point in time.
>>>
>>> *Closed World Assumption*: Archetypes help express what an author wants
>>> to document. These are very subjective truths at a point in time.
>>>
>>> This

Re: [Troll] Terminology bindings ... again

In addition to this, OpenEhr tends to the use of simple precoordinated
concepts, that is because the archetypes explain the details.

It is, for example, rare in OpenEhr to use the concept for "bloodpressure
sitting". Normally one would create two leafnodes, one with the concept for
"bloodpressure", the other for "sitting". This level of expressing detail
in archetypes is historically grown in the years from before SNOMED, and it
seems like a blessing now, because it makes the discussion about concepts
with complex meaning a bit superfluous.

Avoid complex meanings in leaf nodes and express complexity in archetype
structure, and the number of different concepts to be used will be reduced
and the chance of availability of needed concepts rises.

The message is simple:  don't allow items with complex meanings in
leafnodes, but use archetypes to represent complexity.

Op ma 2 apr. 2018 23:35 schreef A Verhees <bert.verh...@rosa.nl>:

> GF: "When we add to all this that only part of the epistemology can be
> pre-coordinated it means that part of the temporal aspects for instance can
> NOT be dealt with in SNOMED, then we have the situation that part of the
> epistemology is in SNOMED and part defined in the Archetype/Template."
> ---
> Using SNOMED does not block using other terminologies or even local
> terminologies.
>
> In OpenEhr is always a part of the epistemology in the context of the
> archetype, that is its power. Terminologies serve to undoubtable define the
> presented data-item or act as a data-item. This is also the case in CEN13606
>
>
>>
>> Gerard   Freriks
>> +31 620347088
>>   gf...@luna.nl
>>
>> Kattensingel  20
>> 2801 CA Gouda
>> the Netherlands
>>
>> On 2 Apr 2018, at 20:02, Pablo Pazos <pablo.pa...@cabolabs.com> wrote:
>>
>> Yes, but the main topic here is the use of SNOMED inside openEHR, so
>> there is no terminology world separated from the content modeling and data
>> recording world. We will use SNOMED inside the openEHR context, so the
>> SNOMED meaning will be constrained by the openEHR meaning when recording
>> clinical information. We should be constraint to that context.
>>
>> On Mon, Apr 2, 2018 at 6:01 AM, GF <gf...@luna.nl> wrote:
>>
>>> Pablo,
>>>
>>> It is as Thomas and I wrote.
>>>
>>> *Open world Assumption:* Ontologies declare absolute truths
>>> irrespective of geographical location and point in time.
>>>
>>> *Closed World Assumption*: Archetypes help express what an author wants
>>> to document. These are very subjective truths at a point in time.
>>>
>>> This subtle but important distinction is only one of the reasons to
>>> refrain from the use of pre-coorodinated SNOMED terms. Things like these
>>> matter when we start to reason about the documented patient data.
>>>
>>> Gerard   Freriks
>>> +31 620347088 <+31%206%2020347088>
>>>   gf...@luna.nl
>>>
>>> Kattensingel  20
>>> 2801 CA Gouda
>>> the Netherlands
>>>
>>> On 2 Apr 2018, at 01:11, Pablo Pazos <pablo.pa...@cabolabs.com> wrote:
>>>
>>> I'm sorry but "...no cancer was, is, or will be present." doesn't even
>>> make sense. No system can record what can or can't happen in the future,
>>> and that concept is not part of any terminology AFAIK.
>>>
>>> On Sun, Apr 1, 2018 at 7:35 PM, GF <gf...@luna.nl> wrote:
>>>
>>>> Thomas,
>>>>
>>>> OpenEHR and 13606 deal with Closed World Assumption systems.
>>>> And therefor both mean in the case of 'No Cancer' that Cancer was not
>>>> found in the database or that No Cancer was the documented result of an
>>>> evaluation.
>>>> Both statements are documented things in a Template that according to
>>>> the author cancer is not found.
>>>> But any time in the future it might.
>>>>
>>>> 'No Cancer' as pre-coordinated term in the case of SNOMED means that no
>>>> cancer was, is, or will be present.
>>>>
>>>> Gerard   Freriks
>>>> +31 620347088 <+31%206%2020347088>
>>>>   gf...@luna.nl
>>>>
>>>> Kattensingel  20
>>>> 2801 CA Gouda
>>>> the Netherlands
>>>>
>>>> On 1 Apr 2018, at 14:41, Thomas Beale <thomas.be...@openehr.org> wrote:
>>>>
>>>>
>>>> On 01/04/2018 13:16, GF wrote:
>>>>
>>>> Pre-coordinated SNOMED codes are like classifications, in tha

Re: [Troll] Terminology bindings ... again

GF: "When we add to all this that only part of the epistemology can be
pre-coordinated it means that part of the temporal aspects for instance can
NOT be dealt with in SNOMED, then we have the situation that part of the
epistemology is in SNOMED and part defined in the Archetype/Template."
---
Using SNOMED does not block using other terminologies or even local
terminologies.

In OpenEhr is always a part of the epistemology in the context of the
archetype, that is its power. Terminologies serve to undoubtable define the
presented data-item or act as a data-item. This is also the case in CEN13606


>
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 2 Apr 2018, at 20:02, Pablo Pazos  wrote:
>
> Yes, but the main topic here is the use of SNOMED inside openEHR, so there
> is no terminology world separated from the content modeling and data
> recording world. We will use SNOMED inside the openEHR context, so the
> SNOMED meaning will be constrained by the openEHR meaning when recording
> clinical information. We should be constraint to that context.
>
> On Mon, Apr 2, 2018 at 6:01 AM, GF  wrote:
>
>> Pablo,
>>
>> It is as Thomas and I wrote.
>>
>> *Open world Assumption:* Ontologies declare absolute truths irrespective
>> of geographical location and point in time.
>>
>> *Closed World Assumption*: Archetypes help express what an author wants
>> to document. These are very subjective truths at a point in time.
>>
>> This subtle but important distinction is only one of the reasons to
>> refrain from the use of pre-coorodinated SNOMED terms. Things like these
>> matter when we start to reason about the documented patient data.
>>
>> Gerard   Freriks
>> +31 620347088 <+31%206%2020347088>
>>   gf...@luna.nl
>>
>> Kattensingel  20
>> 2801 CA Gouda
>> the Netherlands
>>
>> On 2 Apr 2018, at 01:11, Pablo Pazos  wrote:
>>
>> I'm sorry but "...no cancer was, is, or will be present." doesn't even
>> make sense. No system can record what can or can't happen in the future,
>> and that concept is not part of any terminology AFAIK.
>>
>> On Sun, Apr 1, 2018 at 7:35 PM, GF  wrote:
>>
>>> Thomas,
>>>
>>> OpenEHR and 13606 deal with Closed World Assumption systems.
>>> And therefor both mean in the case of 'No Cancer' that Cancer was not
>>> found in the database or that No Cancer was the documented result of an
>>> evaluation.
>>> Both statements are documented things in a Template that according to
>>> the author cancer is not found.
>>> But any time in the future it might.
>>>
>>> 'No Cancer' as pre-coordinated term in the case of SNOMED means that no
>>> cancer was, is, or will be present.
>>>
>>> Gerard   Freriks
>>> +31 620347088 <+31%206%2020347088>
>>>   gf...@luna.nl
>>>
>>> Kattensingel  20
>>> 2801 CA Gouda
>>> the Netherlands
>>>
>>> On 1 Apr 2018, at 14:41, Thomas Beale  wrote:
>>>
>>>
>>> On 01/04/2018 13:16, GF wrote:
>>>
>>> Pre-coordinated SNOMED codes are like classifications, in that they are
>>> used at the user level, the User Interface,
>>> The Ontology behind SNOMED allows the pre-ordinated codes to be
>>> decomposed in its constituents.
>>> These decomposed primitive codes can be used in structures like
>>> archetypes at the proper places.
>>> In this way the pre-coorodinated SNOMED codes are iso-semantic.
>>>
>>> But we keep the semantic differences codes expressed  using the SNOMED
>>> ontology and the Archetype and its codes.
>>> Ontologies have the Open World Assumption. A pre-corodinated code like:
>>> No-Cancer means never there was, is or will be cancer. Ontologies describe
>>> reality.
>>> In archetypes that use the Closed World Assumption Diagnosis=cancer,
>>> PresenceModifier=No means No Cancer found but perhaps they are. It just was
>>> not found. Presence of absence in a database are described.
>>>
>>>
>>> I'm unclear why you call this a use of the closed world assumption: the
>>> entire openEHR framework is for building HISs that enable reporting of
>>> reality as it is known to those working in it. So if they put 'No cancer'
>>> that just means that the current clinical thinking for some patient, *with
>>> respect to some investigation*, is that the original presenting problem
>>> is not cancer.
>>>
>>> That never means that the patient doesn't have cancer in their body
>>> somewhere, it just means that the currently investigated signs and symptoms
>>> don't relate to cancer, according to the the investigation carried out.
>>> Even that can be overturned later. But everyone assumes this - the EHR is
>>> always understood as an 'open world' system, where absence of X doesn't
>>> mean negation of X, it just means that no-one has investigated X.
>>>
>>> - thomas
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>>
>>>

Re: SV: [Troll] Terminology bindings ... again

Sorry, this was a reply to Philippe on his message on 14:07

Op ma 2 apr. 2018 15:16 schreef A Verhees <bert.verh...@rosa.nl>:

> Mostly a patients history is regarded in a consultation. Mostly this is
> history from after the start of the electronical era and being treated in
> the Netherlands . At least it is common practice in the Netherlands for
> most patients.
>
> Op ma 2 apr. 2018 14:30 schreef Thomas Beale <thomas.be...@openehr.org>:
>
>>
>>
>> On 02/04/2018 10:59, Philippe Ameline wrote:
>>
>> Le 01/04/2018 à 14:13, Thomas Beale a écrit :
>>
>>
>> just by means of clarification for some readers, since I happen to know
>> how both openEHR and Philippe's system works, here's the way to understand
>> how openEHR would perform the same function as Ligne-de-vie (which it can):
>>
>>- build a lot of CLUSTER archetypes, and probably more OBSERVATION
>>ones; each CLUSTER archetype would be one of the 'trees' Philippe talks
>>about
>>- each of those CLUSTER archetypes has slot nodes that indicate where
>>subordinate CLUSTER archetypes join, and which ones are allowed, in the
>>usual openEHR fashion;
>>- remember, a slot can allow multiple possible substitutions
>>- at run time, a form containing a top level Entry, usually an
>>OBSERVATION will be deployed on the screen, and by a process of user 
>> choice
>>/ UI movements etc, the data will get filled in, and subordinate CLUSTER
>>archetypes will be chosen on the way, and filled in along the way.
>>
>> This mode of operation is known by us in openEHR-land as 'dynamic
>> slot-filling' or 'runtime templating', as opposed to the more typical
>> design-time templating used in a lot of systems, where most of the choices
>> are made prior to runtime. But openEHR systems do use runtime slot-filling
>> as well, e.g. for writing discharge summaries and referrals, where the data
>> items are only knowable in the encounter or report-writing session.
>>
>>
>> This trend allows me to discover that openEHR already became a rich
>> ecosystem. Isn't this technique close from Gerard's vision of archetypes as
>> "context for concepts" in a kind of ontology?
>>
>> However, I probably wrongly expressed what I wanted to say, and is more
>> theoretical than comparing implementations, such as openEHR and Ligne de
>> vie.
>>
>> When we talk to one another using a natural language, we just need a
>> vocabulary and a grammar. The grammar is simply a set of rules, but not a
>> physical pattern. We say "John sees the green house" and not "John as the
>> subject sees as the verb the green as an adjective house as a noon in a
>> position of direct object complement".
>>
>> In the same way, it is possible to express a structured discourse just
>> using an ontology and a grammatical structure (say trees) without the need
>> of any structure description.
>>
>>
>> you are I think using 'grammar' in an unusual way - normally it means the
>> set of production rules that define legal utterances in some language; this
>> is an intensional definition, i.e. it can be used computationally to parse
>> actual utterances (including garbage) and generate structures only for the
>> utterances obeying the rules of the grammar.
>>
>> In your usage, 'grammar' is what you call the trees, which are
>> extensional maps of legal utterances, or fragments of utterances, which can
>> only be connected together according to their rules, which ensure
>> correctness of larger utterances, e.g. a colonoscopy report.
>>
>> Structurally and computationally then, the fils guides (the trees in
>> Ligne de Vie) and archetypes are the same; they differ only in
>> representational details. However, there are two semantic differences.
>>
>> Firstly, the fils guides depend completely on the ontology (which is an
>> ontological terminology, to give it a more correct name, I think), and the
>> two things are built as a combined representational system. Whereas
>> elements in archetypes can have bindings made to ontologies and/or
>> terminologies, but don't rely on them, since they can rely on their
>> internal terminology to a reasonable extent (but not for value sets like
>> procedure or diagnoses etc). In theory, we should do what fils guides are
>> doing, and the reason we have not is only practical, not theoretical: the
>> development of bio-medical ontologies is still young, and was almost
>> non-existent 18 years ago when we started on this.
>>
>>

Re: SV: [Troll] Terminology bindings ... again

> The "good all" SOAP is dead ; nowadays, the encounter stream is switching
to (AP)SO(A'P'):
> people now come with an existing set of Assessments and Procedures,
> not "just" with "Subjective" issues.

>
Wasn't that always the case?
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: [Troll] Terminology bindings ... again

2018-03-31 Thread A Verhees

Style can be explained, please do.
Documentation ontology can be useful. Please send that too.

Thanks
Bert

Op za 31 mrt. 2018 13:27 schreef GF <gf...@luna.nl>:

> What do you expect from a technical description when it comes to styles?
> Under the hood one sees no striking differences.
> Archetype nodes are archetype nodes, leafnodes are leafnodes.
> What is different is the way one uses ADL to constrain the RM.
>
> Or do you mean to see the documentation Ontology?
>
>
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 31 Mar 2018, at 13:04, A Verhees <bert.verh...@rosa.nl> wrote:
>
> Okay. Do you have a technical description of what you are talking about?
>
> Thanks
> Bert
>
>
> ___
> 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: [Troll] Terminology bindings ... again

2018-03-31 Thread A Verhees

Sorry, I am reading on my phone and it seems I missed an email. I read
further day after tomorrow when I have a descent email client.

Best regards
Bert

Op za 31 mrt. 2018 13:06 schreef A Verhees <bert.verh...@rosa.nl>:

> Okay. Do you have a technical description of what you are talking about?
>
> Thanks
> Bert
>
> Op za 31 mrt. 2018 12:31 schreef GF <gf...@luna.nl>:
>
>> In my opinion there is something essential missing, so far.
>>
> What is missing is a collection of standard Cluster archetypes/Patterns
>> that can be used to create any story, describing the
>> observation/evaluation/planning/ordering and action processes including all
>> the possible contexts.
>> All the Archetype Patterns create one Documentation ontology.
>>
>> That Documentation ontology as grammar combined with a terminology like
>> SNOMED and LOINC looks like Phillipe's system.
>>
>
>>
>> Gerard   Freriks
>> +31 620347088
>>   gf...@luna.nl
>>
>> Kattensingel  20
>> 2801 CA Gouda
>> the Netherlands
>>
>> On 31 Mar 2018, at 11:38, Philippe Ameline <philippe.amel...@free.fr>
>> wrote:
>>
>> Diego,
>>
>> IMHO your contribution is orthogonal to what Thomas very accurately
>> explained. Building subset is a symptom of the issue, not a solution.
>>
>> As I tried to explain in my initial post, we are currently facing two
>> generation of technologies in medicine:
>> - systems that record information as trees of atomic concepts, in the
>> same way we are all exchanging in "globish" by inserting English concepts
>> in a grammatical structure,
>> - systems that still rely on a fixed database schema and usually have a
>> "discourse system" limited to field/value pairs.
>>
>> When I try to explain all this to lesser tech-savvy people (means, who
>> don't belong to this list ;-) ), I usually explain that:
>> - usual systems (with an information schema tied to a database schema)
>> are like a printed form. The day after you received the 5000 printed sheet
>> you ordered, you will realize that there are several design flaws that you
>> will have to endure while the stock is not empty,
>> - openEHR is a flexible schema, similar to a set of stamps that lets you
>> build forms dynamically from blank paper. If your design has to evolve, you
>> just have to adapt one of the stamps.
>> - in my system, based on an ontology and a dependency grammar, you can
>> use stamps (archetypes like) and/or "write" freely.
>>
>> I have always understood openEHR as a link, a step, between the "good old
>> way" (discourse range hard coded into a database schema) and a modern
>> approach where you can really "tell a patient story" using a genuine
>> (structured, processable) language. 15 years ago, Thomas and I spent hours
>> discussing the opportunity for openEHR to include a reference ontology in
>> its kernel ; this decision was not made for very good reasons, but I guess
>> that it still remains a necessary evolution.
>>
>> Thomas very accurately explained why SNOMED is a deceptive candidate for
>> such a reference ontology. And, unfortunately, it is deep rooted in its
>> origins as a coding system. I can hear all the arguments about "legacy
>> system" and even "legacy medicine" (the one still fully organized for
>> siloed acute care at a time our society already entered the information age
>> and suffers from chronic diseases). The question remains to guess if SNOMED
>> is a component that lets you stuck in the past or helps you disrupt the
>> legacy craps.
>>
>> Now, let's imagine a modern system that would allow you to "tell a
>> patient medical story" from the various viewpoints of a multidisciplinary
>> patient centered team. What would be the point about having "local
>> vocabulary subsets"? Do you think that a GP shouldn't use the word "mitral
>> leak" or any other "specialized" word in the medical vocabulary?
>>
>> My feeling is that selected subset is a solution when using SNOMED as a
>> coding system. The subset being the global list of values that are legal
>> for the fields in the existing schema, in the same way you will select
>> subsets in a billing system. But when it comes to "telling a story" using a
>> language, in my opinion subsets are a non-sense. We don't use "vocabulary
>> subsets" when we talk, and each contributor in a patient's team would
>> mechanically get exposed to a super-set; subset is actually only fit

Re: [Troll] Terminology bindings ... again

2018-03-31 Thread A Verhees

Okay. Do you have a technical description of what you are talking about?

Thanks
Bert

Op za 31 mrt. 2018 12:31 schreef GF :

> In my opinion there is something essential missing, so far.
> What is missing is a collection of standard Cluster archetypes/Patterns
> that can be used to create any story, describing the
> observation/evaluation/planning/ordering and action processes including all
> the possible contexts.
> All the Archetype Patterns create one Documentation ontology.
>
> That Documentation ontology as grammar combined with a terminology like
> SNOMED and LOINC looks like Phillipe's system.
>
>
> Gerard   Freriks
> +31 620347088
>   gf...@luna.nl
>
> Kattensingel  20
> 2801 CA Gouda
> the Netherlands
>
> On 31 Mar 2018, at 11:38, Philippe Ameline 
> wrote:
>
> Diego,
>
> IMHO your contribution is orthogonal to what Thomas very accurately
> explained. Building subset is a symptom of the issue, not a solution.
>
> As I tried to explain in my initial post, we are currently facing two
> generation of technologies in medicine:
> - systems that record information as trees of atomic concepts, in the same
> way we are all exchanging in "globish" by inserting English concepts in a
> grammatical structure,
> - systems that still rely on a fixed database schema and usually have a
> "discourse system" limited to field/value pairs.
>
> When I try to explain all this to lesser tech-savvy people (means, who
> don't belong to this list ;-) ), I usually explain that:
> - usual systems (with an information schema tied to a database schema) are
> like a printed form. The day after you received the 5000 printed sheet you
> ordered, you will realize that there are several design flaws that you will
> have to endure while the stock is not empty,
> - openEHR is a flexible schema, similar to a set of stamps that lets you
> build forms dynamically from blank paper. If your design has to evolve, you
> just have to adapt one of the stamps.
> - in my system, based on an ontology and a dependency grammar, you can use
> stamps (archetypes like) and/or "write" freely.
>
> I have always understood openEHR as a link, a step, between the "good old
> way" (discourse range hard coded into a database schema) and a modern
> approach where you can really "tell a patient story" using a genuine
> (structured, processable) language. 15 years ago, Thomas and I spent hours
> discussing the opportunity for openEHR to include a reference ontology in
> its kernel ; this decision was not made for very good reasons, but I guess
> that it still remains a necessary evolution.
>
> Thomas very accurately explained why SNOMED is a deceptive candidate for
> such a reference ontology. And, unfortunately, it is deep rooted in its
> origins as a coding system. I can hear all the arguments about "legacy
> system" and even "legacy medicine" (the one still fully organized for
> siloed acute care at a time our society already entered the information age
> and suffers from chronic diseases). The question remains to guess if SNOMED
> is a component that lets you stuck in the past or helps you disrupt the
> legacy craps.
>
> Now, let's imagine a modern system that would allow you to "tell a patient
> medical story" from the various viewpoints of a multidisciplinary patient
> centered team. What would be the point about having "local vocabulary
> subsets"? Do you think that a GP shouldn't use the word "mitral leak" or
> any other "specialized" word in the medical vocabulary?
>
> My feeling is that selected subset is a solution when using SNOMED as a
> coding system. The subset being the global list of values that are legal
> for the fields in the existing schema, in the same way you will select
> subsets in a billing system. But when it comes to "telling a story" using a
> language, in my opinion subsets are a non-sense. We don't use "vocabulary
> subsets" when we talk, and each contributor in a patient's team would
> mechanically get exposed to a super-set; subset is actually only fit for
> silos... and at a time when medicine is already becoming a narrow silo in
> health, I really don't see it as a sound strategy.
>
> Best,
>
> Philippe
>
> Le 23/03/2018 à 10:49, Diego Boscá a écrit :
>
> IMO having both representations (pre and postcordinated) is not bad per se
> (in fact, knowing that they are equivalent is pretty good). The main
> problem is that technical people (including myself) shouldn't just dump the
> entire snomed ct into a data field and call it a day. To design better and
> useful systems you need a first "curation" phase where you define your
> relevant subsets that fit your system. The boundary problem is less of a
> problem if even if different terms were used when the record was created we
> can assess that they are in fact the same thing.
> I think people are a little unaware of this step and causes problems as
> the ones you and Thomas mentioned
>
> 2018-03-23 10:35 GMT+01:00 Bakke, Silje Ljosland <

Re: [Troll] Terminology bindings ... again

2018-03-31 Thread Bert Verhees


On 31-03-18 12:11, GF wrote:

Both styles are possible with any RM.
It is a choice.

Do you mean, inside OpenEhr by using the GenericEntry?
Or are there other entry-types possible also?



Most archetype modellers use the Class-Attribute / Archetype Node style.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

On 31 Mar 2018, at 11:04, Bert Verhees <bert.verh...@rosa.nl 
<mailto:bert.verh...@rosa.nl>> wrote:


Maybe we should relate this thinking to CEN13606 because that 
Reference Model allows more generic thinking.

(Thinking this because GF was the convenor of this CEN standard)

But even then some more explanation would be welcome.

Bert




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

2018-03-31 Thread Bert Verhees

Maybe we should relate this thinking to CEN13606 because that Reference 
Model allows more generic thinking.

(Thinking this because GF was the convenor of this CEN standard)

But even then some more explanation would be welcome.

Bert

On 31-03-18 10:37, GF wrote:

Dear Thomas,

There are two possible Modelling styles:
*- Archetype Leafnode style (Element-Data style)*
Specialisation by changing the Element Data field
Each archetype is a fixed, standardised, pattern, a mini-ontology
The fixed path to the leaf-node defines the full meaning of that leaf-node

*- Archetype Node style (Class-Attribute style)*
Specialisation by changing node names in the archetype
Each archetype makes use of  non-standard patterns.
The meaning is changed by changing node names.

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

Kattensingel  20
2801 CA Gouda
the Netherlands

On 30 Mar 2018, at 18:07, Thomas Beale > wrote:


Gerard,

I don't know that your modelling approach is that far from openEHR - 
you are from memory using CLUSTER in a way we are not, but I don't 
recall the details. In any case, is there a recent reference page on 
the web where a technical summary of your modelling style can be seen?


thanks

- thomas


On 30/03/2018 16:49, GF wrote:

Philippe,

Fist of all: My ideas about modelling and using archetype, etc is 
not shared by OpenEhr


I agree that the tree is important.
My tree starts at Composition contaiining one of more Sections, 
and/or Entries.
The Entry models a process of one of these: data observation, data 
evaluation, data planning, data ordering and data about events/actions.
Each of these models deal with the full epistemology of that topic 
using standardised patterns/Clusters/Archetypes
That what is observed is a Cluster archetype that models the datum 
plus its context/epistemology.


What is important is the Modelling Style.
In OpenEhr the nodes of the Archetype are changed.
In my style, since I make use of predefined patterns I will not 
change the nodes but change the data in the Elements.
In my style of modelling querying the leaves is that what is done. 
The unique path defines its meaning.
In my way of modelling the collection of paths is a kind of ontology 
for data in healthcare records.





--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Team, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 


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


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




___
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: openEHR Toolkit

2018-03-29 Thread Bert Verhees


On 29-03-18 13:59, Pablo Pazos wrote:

this is a simple app, Java only.

Still very nice and useful and inspiring ;-)

It is just, I am working on micro-services, also for OpenEhr, which 
makes it easy to have a cloud of modularity which can also interact.
But of course, it is work to create a base-environment, weeks, maybe 
months at least, I guess you have other priorities and we live only once ;-)


good luck
Bert


On Thu, Mar 29, 2018, 04:04 A Verhees <bert.verh...@rosa.nl 
<mailto:bert.verh...@rosa.nl>> wrote:




Op do 29 mrt. 2018 02:39 schreef Pablo Pazos <pablo@gmail.com
<mailto:pablo@gmail.com>>:

For now this is just a place that integrates some of the tools
I developed, and will add more soon.
If you have open tools developed in Java, I can try to
integrate them into the CoT.


It is Java only? I was hoping for an open architecture.  Is it an
idea to refactor it in that way?


On Mar 28, 2018 3:58 AM, "A Verhees" <bert.verh...@rosa.nl
<mailto:bert.verh...@rosa.nl>> wrote:

Very interesting  initiative. Is it an idea to make it
some kind an open framework/platform infrastructure so
that other developers can collaborate or hang their
software in?

Op wo 28 mrt. 2018 05:40 schreef Pablo Pazos
<pablo.pa...@cabolabs.com <mailto:pablo.pa...@cabolabs.com>>:

Hi all,

I have released a humble pack of tools to help
developers working with openEHR and the EHRServer.

This is a pre-alpha version, I'm looking for feedback.
Any service idea, improvements, comments, etc. are
very welcome!

Please give it a try:
http://server001.cloudehrserver.com/cot/

We have many areas of improvements :)

-- 
Ing. Pablo Pazos Gutiérrez

pablo.pa...@cabolabs.com <mailto:pablo.pa...@cabolabs.com>
+598 99 043 145
skype: cabolabs
<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
<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



___
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: openEHR Toolkit

2018-03-29 Thread A Verhees

Op do 29 mrt. 2018 02:39 schreef Pablo Pazos <pablo@gmail.com>:

> For now this is just a place that integrates some of the tools I
> developed, and will add more soon.
> If you have open tools developed in Java, I can try to integrate them into
> the CoT.
>

It is Java only? I was hoping for an open architecture.  Is it an idea to
refactor it in that way?


> On Mar 28, 2018 3:58 AM, "A Verhees" <bert.verh...@rosa.nl> wrote:
>
> Very interesting  initiative. Is it an idea to make it some kind an open
> framework/platform infrastructure so that other developers can collaborate
> or hang their software in?
>
> Op wo 28 mrt. 2018 05:40 schreef Pablo Pazos <pablo.pa...@cabolabs.com>:
>
>> Hi all,
>>
>> I have released a humble pack of tools to help developers working with
>> openEHR and the EHRServer.
>>
>> This is a pre-alpha version, I'm looking for feedback. Any service idea,
>> improvements, comments, etc. are very welcome!
>>
>> Please give it a try: http://server001.cloudehrserver.com/cot/
>>
>> We have many areas of improvements :)
>>
>> --
>> Ing. Pablo Pazos Gutiérrez
>> pablo.pa...@cabolabs.com
>> +598 99 043 145
>> skype: cabolabs
>> <http://cabolabs.com/>
>> http://www.cabolabs.com
>> https://cloudehrserver.com
>> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: openEHR Toolkit

2018-03-28 Thread A Verhees

Very interesting  initiative. Is it an idea to make it some kind an open
framework/platform infrastructure so that other developers can collaborate
or hang their software in?

Op wo 28 mrt. 2018 05:40 schreef Pablo Pazos :

> Hi all,
>
> I have released a humble pack of tools to help developers working with
> openEHR and the EHRServer.
>
> This is a pre-alpha version, I'm looking for feedback. Any service idea,
> improvements, comments, etc. are very welcome!
>
> Please give it a try: http://server001.cloudehrserver.com/cot/
>
> We have many areas of improvements :)
>
> --
> Ing. Pablo Pazos Gutiérrez
> pablo.pa...@cabolabs.com
> +598 99 043 145
> skype: cabolabs
> 
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter 
> ___
> 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: [Troll] Terminology bindings ... again

2018-03-26 Thread Bert Verhees


Thanks, William, I know art-decor, very inspiring, and very usable models.
It helped me in the past a lot with designing archetypes and other 
information models


But as far as I could see subsets in it they were very much bounded to 
an item in a model, so not very easy to use or to find if one would want 
to create another model.


So I am not sure if they can be compared with the NHS where they have 
more generic listings of subjects: "SNOMED CT human-readable subset - 
Gastroenterology" or "SNOMED CT human-readable subset - Gynaecology", so 
not bounded to a specific model but rather to a sub-domain of clinical 
knowledge/practice


Do we have that kind of subsets in the Netherlands?

Bert


On 26-03-18 09:31, wgoos...@results4care.nl wrote:


Creating subsets is the case in the Netherlands.

However they are published in different fashions:

  * As national extensions in SnomedCT online
  * On Nictiz art decor for projects as perinatology (varied sets for
data and for valuesets)
  * On zorginformatiebouwstenen
  * On the FHIR publication sites
  * On project sites
  * On github Detailed Clinical Models in individual DCMs
  * And probably more.

Dr William Goossen
Directeur
Results 4 Care bv
Tel +31654614458

*Van: *openehr-technical-requ...@lists.openehr.org 
<mailto:openehr-technical-requ...@lists.openehr.org>

*Verzonden: *maandag 26 maart 2018 08:26
*Aan: *openehr-technical@lists.openehr.org 
<mailto:openehr-technical@lists.openehr.org>

*Onderwerp: *openEHR-technical Digest, Vol 73, Issue 86

Send openEHR-technical mailing list submissions to

 openehr-technical@lists.openehr.org

To subscribe or unsubscribe via the World Wide Web, visit

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

or, via email, send a message with subject or body 'help' to

openehr-technical-requ...@lists.openehr.org

You can reach the person managing the list at

openehr-technical-ow...@lists.openehr.org

When replying, please edit your Subject line so it is more specific

than "Re: Contents of openEHR-technical digest..."

Today's Topics:

   1. Re: SV: [Troll] Terminology bindings ... again (A Verhees)

--

Message: 1

Date: Mon, 26 Mar 2018 06:25:19 +

From: A Verhees <bert.verh...@rosa.nl>

To: For openEHR technical discussions

<openehr-technical@lists.openehr.org>

Subject: Re: SV: [Troll] Terminology bindings ... again

Message-ID:

<cafl--x9otb+k-zef1lvzbjp8j6bge6d3dtq_pnc0hclkp92...@mail.gmail.com>

Content-Type: text/plain; charset="utf-8"

Thanks Mikael, very interesting. I will check if they do that in the

Netherlands too.

Bert

Op ma 26 mrt. 2018 08:10 schreef Mikael Nystr?m <mikael.nyst...@liu.se>:

> Hi Bert,

>

>

>

> Most countries (or big organizations) that start to use SNOMED CT 
creates


> those kinds of subsets of SNOMED CT to make it more manageable. See for

> example NHS in England

> https://isd.digital.nhs.uk/trud3/user/guest/group/0/pack/40 .

>

>

>

>  Regards

>

>  Mikael

>

>

>

>

>

> *Fr?n:* openEHR-technical [mailto:

> openehr-technical-boun...@lists.openehr.org] *F?r *Bert Verhees

> *Skickat:* den 23 mars 2018 20:01

>

>

> *Till:* openehr-technical@lists.openehr.org

> *?mne:* Re: SV: [Troll] Terminology bindings ... again

>

>

>

> Diego, this is a wise thought!!!

> It seems logical, but that is often in good ideas, they seem like: 
why did


> no one ever think about this.

>

> No clinician handles the complete medical science/SNOMED repository 
in his


> profession. Some even use a very small sub-part, think about a 
dentist, a


> physiotherapist, a midwife

> For some is it also the case that not only the subjects are 
different, but


> also how deep the details must go. For some professions it is not

> interesting to know if blood-pressure was measured lying or sitting.

>

> It looks like a good idea if the SNOMED repository will be split up for

> professions, maybe that needs to be done on national level, because the

> clinical profession-structure can differ in countries.

> The rest of the database should be there for second searches, for

> interpreting codes which come from other professions.

>

> I hope someone will pick up this idea, because it is hardly to be 
done for


> individuals. It needs to be done by national SNOMED maintenance teams.

>

> Bert

>

>

> On 23-03-18 10:49, Diego Bosc? wrote:

>

> IMO having both representations (pre and postcordinated) is not bad 
per se


> (in fact, knowing that they are equivalent is pretty good). The main

> problem is that technical people (including myself) shouldn't just 
dump the

Re: SV: [Troll] Terminology bindings ... again

2018-03-26 Thread A Verhees

Thanks Mikael, very interesting. I will check if they do that in the
Netherlands too.

Bert

Op ma 26 mrt. 2018 08:10 schreef Mikael Nyström <mikael.nyst...@liu.se>:

> Hi Bert,
>
>
>
> Most countries (or big organizations) that start to use SNOMED CT creates
> those kinds of subsets of SNOMED CT to make it more manageable. See for
> example NHS in England
> https://isd.digital.nhs.uk/trud3/user/guest/group/0/pack/40 .
>
>
>
>  Regards
>
>  Mikael
>
>
>
>
>
> *Från:* openEHR-technical [mailto:
> openehr-technical-boun...@lists.openehr.org] *För *Bert Verhees
> *Skickat:* den 23 mars 2018 20:01
>
>
> *Till:* openehr-technical@lists.openehr.org
> *Ämne:* Re: SV: [Troll] Terminology bindings ... again
>
>
>
> Diego, this is a wise thought!!!
> It seems logical, but that is often in good ideas, they seem like: why did
> no one ever think about this.
>
> No clinician handles the complete medical science/SNOMED repository in his
> profession. Some even use a very small sub-part, think about a dentist, a
> physiotherapist, a midwife
> For some is it also the case that not only the subjects are different, but
> also how deep the details must go. For some professions it is not
> interesting to know if blood-pressure was measured lying or sitting.
>
> It looks like a good idea if the SNOMED repository will be split up for
> professions, maybe that needs to be done on national level, because the
> clinical profession-structure can differ in countries.
> The rest of the database should be there for second searches, for
> interpreting codes which come from other professions.
>
> I hope someone will pick up this idea, because it is hardly to be done for
> individuals. It needs to be done by national SNOMED maintenance teams.
>
> Bert
>
>
> On 23-03-18 10:49, Diego Boscá wrote:
>
> IMO having both representations (pre and postcordinated) is not bad per se
> (in fact, knowing that they are equivalent is pretty good). The main
> problem is that technical people (including myself) shouldn't just dump the
> entire snomed ct into a data field and call it a day. To design better and
> useful systems you need a first "curation" phase where you define your
> relevant subsets that fit your system. The boundary problem is less of a
> problem if even if different terms were used when the record was created we
> can assess that they are in fact the same thing.
>
> I think people are a little unaware of this step and causes problems as
> the ones you and Thomas mentioned
>
> 2018-03-23 10:35 GMT+01:00 Bakke, Silje Ljosland <
> silje.ljosland.ba...@nasjonalikt.no>:
>
> I read Thomas’ reply with great interest, and I generally agree that with
> a well thought out information model, the very detailed precoordinated
> expressions are redundant. At the same time I understand Mikael’s point of
> view too. BUT, what I’m often met with is that because these precoordinated
> expressions exist (like for example “lying blood pressure” and “sitting
> blood pressure”), we should use them INSTEAD OF using our clever
> information models (that we do have) for recording new data.
>
>
>
> In my opinion this is wrong because it doesn’t take into account that
> healthcare is unpredictable, and this makes recording more difficult for
> the clinician. How many different variations would you have to select from?
> Take the made up example “sitting systolic blood pressure with a medium
> cuff on the left upper arm”; this will be a lot of possible permutations,
> especially if you take into account all the different permutations where
> one or more variable isn’t relevant.
>
>
>
> So while I don’t think the existence of these precoordinated terms in
> itself is a problem, it’s a potential problem that people get a bit
> overzealous with them.
>
>
>
> Regards,
>
> *Silje*
>
>
>
> *From:* openEHR-technical <openehr-technical-boun...@lists.openehr.org> *On
> Behalf Of *Mikael Nyström
> *Sent:* Friday, March 23, 2018 10:06 AM
> *To:* For openEHR technical discussions <
> openehr-technical@lists.openehr.org>
> *Subject:* SV: SV: [Troll] Terminology bindings ... again
>
>
>
> Hi tom,
>
>
>
> I can agree with you that if SNOMED CT was created when all patients in
> the world already had all information in their health record recorded using
> cleverly built and structured information models (like archetypes,
> templates and similar), but that is not the case. Instead SNOMED CT also
> tries to help healthcare organizations to do something better also with
> their already recorded health record information, because that

Re: SV: [Troll] Terminology bindings ... again

2018-03-23 Thread Bert Verhees

Diego, this is a wise thought!!!
It seems logical, but that is often in good ideas, they seem like: why 
did no one ever think about this.

No clinician handles the complete medical science/SNOMED repository in 
his profession. Some even use a very small sub-part, think about a 
dentist, a physiotherapist, a midwife
For some is it also the case that not only the subjects are different, 
but also how deep the details must go. For some professions it is not 
interesting to know if blood-pressure was measured lying or sitting.

It looks like a good idea if the SNOMED repository will be split up for 
professions, maybe that needs to be done on national level, because the 
clinical profession-structure can differ in countries.
The rest of the database should be there for second searches, for 
interpreting codes which come from other professions.

I hope someone will pick up this idea, because it is hardly to be done 
for individuals. It needs to be done by national SNOMED maintenance teams.

Bert

On 23-03-18 10:49, Diego Boscá wrote:
IMO having both representations (pre and postcordinated) is not bad 
per se (in fact, knowing that they are equivalent is pretty good). The 
main problem is that technical people (including myself) shouldn't 
just dump the entire snomed ct into a data field and call it a day. To 
design better and useful systems you need a first "curation" phase 
where you define your relevant subsets that fit your system. The 
boundary problem is less of a problem if even if different terms were 
used when the record was created we can assess that they are in fact 
the same thing.
I think people are a little unaware of this step and causes problems 
as the ones you and Thomas mentioned

2018-03-23 10:35 GMT+01:00 Bakke, Silje Ljosland 
>:

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

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

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

Regards,

*Silje*

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

Hi tom,

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

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

 Regards

 Mikael

*Från:*openEHR-technical
[mailto:openehr-technical-boun...@lists.openehr.org
] *För *Thomas
Beale
*Skickat:* den 23 mars 2018 01:06
*Till:* openehr-technical@lists.openehr.org

*Ämne:* Re: SV: [Troll] Terminology bindings ... again

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

1. the problem of a profusion of pre-coordinated and

RE: SV: [Troll] Terminology bindings ... again

2018-03-23 Thread A Verhees

Maybe a match-table which matches pre coordinated expressions to all
possible post coordinated expressions which have the same meaning will be
necessary.

How can you else find data-entries of a specific meaning by filtering on
SNOMED?

Bert

Op 23 mrt. 2018 10:35 schreef "Bakke, Silje Ljosland" <
silje.ljosland.ba...@nasjonalikt.no>:

> I read Thomas’ reply with great interest, and I generally agree that with
> a well thought out information model, the very detailed precoordinated
> expressions are redundant. At the same time I understand Mikael’s point of
> view too. BUT, what I’m often met with is that because these precoordinated
> expressions exist (like for example “lying blood pressure” and “sitting
> blood pressure”), we should use them INSTEAD OF using our clever
> information models (that we do have) for recording new data.
>
>
>
> In my opinion this is wrong because it doesn’t take into account that
> healthcare is unpredictable, and this makes recording more difficult for
> the clinician. How many different variations would you have to select from?
> Take the made up example “sitting systolic blood pressure with a medium
> cuff on the left upper arm”; this will be a lot of possible permutations,
> especially if you take into account all the different permutations where
> one or more variable isn’t relevant.
>
>
>
> So while I don’t think the existence of these precoordinated terms in
> itself is a problem, it’s a potential problem that people get a bit
> overzealous with them.
>
>
>
> Regards,
>
> *Silje*
>
>
>
> *From:* openEHR-technical  *On
> Behalf Of *Mikael Nyström
> *Sent:* Friday, March 23, 2018 10:06 AM
> *To:* For openEHR technical discussions  openehr.org>
> *Subject:* SV: SV: [Troll] Terminology bindings ... again
>
>
>
> Hi tom,
>
>
>
> I can agree with you that if SNOMED CT was created when all patients in
> the world already had all information in their health record recorded using
> cleverly built and structured information models (like archetypes,
> templates and similar), but that is not the case. Instead SNOMED CT also
> tries to help healthcare organizations to do something better also with
> their already recorded health record information, because that information
> to a large extent still belongs to living patients.
>
>
>
> It would be interesting to have your opinion about why it is a real
> problem with the “extra” pre-coordinated concepts in SNOMED CT in general
> and not only for the use case of creating archetypes or what would be
> nicest in theory.
>
>
>
>  Regards
>
>  Mikael
>
>
>
>
>
> *Från:* openEHR-technical [mailto:openehr-technical-
> boun...@lists.openehr.org ] *För
> *Thomas Beale
> *Skickat:* den 23 mars 2018 01:06
> *Till:* openehr-technical@lists.openehr.org
> *Ämne:* Re: SV: [Troll] Terminology bindings ... again
>
>
>
> I have made some attempts to study the problem in the past, not recently,
> so I don't know how much the content has changed in the last 5 years. Two
> points come to mind:
>
>
>
> 1. the problem of a profusion of pre-coordinated and post-coordinatable
> concepts during a *lexically-based choosing process *(which is often just
> on a subset).
>  this can be simulated by the lexical search in any of the Snomed search
> engines, as shown in the screen shots below. Now, the returned list is just
> a bag of lexical matches, not a hierarchy. But - it is clear from just the
> size of the list that it would take time to even find the right one -
> usually there are several matches, e.g. 'blood pressure (obs entity)',
> 'systemic blood pressure', 'systolic blood pressure', 'sitting blood
> pressure', 'stable blood pressure' and many more.
>
> I would contend (and have for years) that things like 'sitting blood
> pressure', 'stable blood pressure', and 'blood pressure unrecordable' are
> just wrong as atomic concepts, each with a separate argument as to why. I
> won't go into any of them now. Let's assume instead that the lexical search
> was done on a subset, and that only observables and findings (why are there
> two?) show up, and that the user clicks through 'blood pressure (observable
> entity)', ignoring the 30 or more other concepts. Then the result is a part
> of the hierarchy, see the final screenshot. I would have a hard time
> building any ontology-based argument for even just this one sub-tree, which
> breaks basic terminology rules such as mutual exclusivity, collective
> exhaustiveness and so on. How would the user choose from this? If they are
> recording systolic systemic arterial BP, lying, do they choose 'systemic
> blood pressure', 'arterial blood pressure', 'systolic blood pressure',
> 'lying blood pressure', or something else.
>
> Most of these terms are pre-coordinated, and the problem would be solved
> by treating the various factors such as patient

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?


On 21-03-18 16:32, GF wrote:

When I’n not mistaken:
Duration is not the same concept as Calendar.
IsoTime and Calendar are both data types defining an absolute point on 
the time line, but in different ways.


In the Java and Golang classes Calendar is also to indicate durations, 
it is in fact, to do Calendar calculations. You can calculate the first 
day (example 2004/1/1) and say, this date + 3 months, and then you get a 
new Date, which is a different number of days away then when the first 
date is 2005/1/1 + 3 months (because of Leap year)


For example, see here the Add function to Add months or weeks or years 
to a date

https://docs.oracle.com/javase/7/docs/api/java/util/Calendar.html#add(int,%20int)

That is what is needed when you calculate in the date range of the 
ISO8601 string.


When you do calculations in the time range, then you need to calculate 
with a Duration (which does in background everything in nanoseconds, but 
has convenience methods to use it for hours and minutes, etc)




Duration is the difference between points on the time line.

My point is that some times we can not/want not use points on the time 
line but use fussier terms like: begin of an event somewhere in 2015, 
or a duration of one month, or


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

Kattensingel  20
2801 CA Gouda
the Netherlands

On 21 Mar 2018, at 15:02, Bert Verhees <bert.verh...@rosa.nl 
<mailto:bert.verh...@rosa.nl>> wrote:


I don't mind how you call it, programmers call it Duration and 
Calendar, both are well known datatypes, but they have other semantics.



On 21-03-18 14:53, GF wrote:


You gave proof that there are different kinds of time.
*Chrono-time* as used fro time stamping at one exact point in time.
And *Chairos-time* used for imprecise relative time as used by humans,

*Chrono-time* is one primitive data type.
*Chairos-time* is defined using archetype/patterns



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

Kattensingel  20
2801 CA Gouda
the Netherlands

On 21 Mar 2018, at 12:25, Bert Verhees <bert.verh...@rosa.nl 
<mailto:bert.verh...@rosa.nl>> wrote:



On 21-03-18 10:50, GF wrote:

Does including Duration in the RM fit with the scope for the RM?

Why do we have archetypes?
Why not include every thing in the RM?
Do we want the HL7v3 Reference Model as it existed many years ago 
and that could not be inspected without a magnifying glass on a 
sheet of paper that was 2 by 1 meters?


Is there one kind of duration?
24 minutes, 5 seconds?
For 2 hours past midnight?
For 2 hours after (clinical) event x
For 2 months after (clinical) event y
2 months cannot be technically represented in a duration, because 
month is not a stable time-definition. It is a Calendar definition.
It is therefor that most major programing languages have a Duration 
and a Calendar class.
Or you say that OpenEhr has no valid Duration-datatype, so always 
express Duration in an archetype (your way),
or say that OpenEhr has a valid Dv_Duration type, and do it right 
(I prefer this way),
or express months as if it is a stable time-indicator and ignore it 
is not (like it is now)


Those are the three possible ways to solve this problem, I think
I am curious to learn what the community will decide.

Bert




___
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 
<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: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

Pieter, the problem are the conflicting semantics. You should avoid 
having conflicting semantics in one class, that is confusing.
I think that is why Java and Golang have both in their standard 
libraries because of the conflicting semantics

There is no good reason to have months and hours in one class.
I must admit, days is a bit in between, although, when looking exact at 
it, one specific day can have in some years one second more or less.
I believe this is always December 31th. So days is more right to put in 
the Calendar class.

But I must leave this discussion, I notice I get involved too much. I 
have given my opinions, and others should give theirs

Best regards
Bert

On 21-03-18 15:52, Pieter Bos wrote:

I don't understand. You can implement a single class ISO8601 Duration, 
containing all the different fields, all optional, that directly maps to and 
from the string representation. You can also easily use it to model both P30D 
and P1M, which are indeed different things. Depending on the fields set, it's 
either very exact or a bit less exact notion of duration.

You should not expect to always to the same calculations with all recorded 
values. How you should exactly handle durations, or dates, or date times, or 
intervals of date times, and if and how you need to split classes, depends on 
the context (archetypes are a very nice tool to define and standardize 
context). The standard ISO8601 types are very useful for having a standard way 
to record date, time, date+time, duration and intervals between fixed points in 
time, with varying precision. And I don't think we need anything else and 
certainly not anything less in the RM.

Also days are not always 24 hours. Next weekend in our time zone we have a 23 
hour day...
That is one reason why some libraries make a different split between the 
concepts than what you call 'calendar' and 'duration'. Also every library and 
standard has its own term for those concepts.

Regards,

Pieter Bos

On 21/03/2018, 14:42, "openEHR-technical on behalf of Bert Verhees" 
<openehr-technical-boun...@lists.openehr.org on behalf of bert.verh...@rosa.nl> wrote:

 No Duration type is a ISO8601 duration, ISO8601 is just a string
 representation of a duration. No programming language can, from its
 standard library safely express an ISO8601 in a class, because the
 ISO8601 is a combination of two types.
 Unless you are wiling to have an uncertainty of 10%, you cannot express
 a month in a Duration type. For many software, this uncertainty is not
 acceptable. Maybe it is for medical purposes, but OpenEhr also has an
 Admin_Entry, and there this uncertainty is not always acceptable. How do
 you bill someone who was one month in a clinic? Make it 28 days or 31 days?

 And the solution is easy, and it has advantages.

 If we split the Dv_Duration in a Calendar part and in a Duration part,

 then both have their own merits. If you want to bill a stay of a month
 in a clinic, you express it by days (which are always 24 hours) P30D
 (represented by the Duration class) and if you want the patient to
 return every month, you can use the first part, P1M (represented by the
 Calendar class).

 I don't think this is complex or requires complex algorithms, even

 opposite, it makes it more simple and more certain to process and all
 the troubles and bad feelings when converting a month to 30 days, and
 then find out it was 28 days, are gone. I think Joda was a complex
 solution for a simple problem.

 Bert

 On 21-03-18 13:47, Pieter Bos wrote:

 > There seems to be some confusion regarding the concept of a ISO8601 
Duration. You can definitely define a duration of 2 months in ISO8601 Durations. 
It has separate fields for years, months, weeks, days, plus an optional time with 
hours, minutes and seconds. All these fields are optional and can all be combined. 
It cannot be fully modelled using a single nanosecond field - you would run into 
trouble with years, months, and even days, plus you cannot express for example a 
duration of 1 hour with no precision in the minutes and seconds fields mentioned. 
I think  https://en.wikipedia.org/wiki/ISO_8601#Durations has a good explanation 
of the concept.
 >
 > The golang Duration type in the time package is _not_ an ISO8601 
duration, but just a duration in nanoseconds, explicitly omitting the definition 
of days. There are libraries available for golang that do model the full iso8601 
duration.
 >
 > Of course, I agree that we should not have a far too big reference 
model. There is a point at which it no longer makes sense to add something to the 
reference model because it is better modelled in an archetype. But I think the 
concept of a duration can be very useful. You could use it to model the examples 
Gerard Freriks mentions for exam

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?


On 21-03-18 15:02, Bert Verhees wrote:
I don't mind how you call it, programmers call it Duration and 
Calendar, both are well known datatypes, but they have other semantics.


Sorry for my unpleasant tone, I guess we are talking about the same things.

Bert

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

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

I don't mind how you call it, programmers call it Duration and Calendar, 
both are well known datatypes, but they have other semantics.



On 21-03-18 14:53, GF wrote:


You gave proof that there are different kinds of time.
*Chrono-time* as used fro time stamping at one exact point in time.
And *Chairos-time* used for imprecise relative time as used by humans,

*Chrono-time* is one primitive data type.
*Chairos-time* is defined using archetype/patterns



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

Kattensingel  20
2801 CA Gouda
the Netherlands

On 21 Mar 2018, at 12:25, Bert Verhees <bert.verh...@rosa.nl 
<mailto:bert.verh...@rosa.nl>> wrote:



On 21-03-18 10:50, GF wrote:

Does including Duration in the RM fit with the scope for the RM?

Why do we have archetypes?
Why not include every thing in the RM?
Do we want the HL7v3 Reference Model as it existed many years ago 
and that could not be inspected without a magnifying glass on a 
sheet of paper that was 2 by 1 meters?


Is there one kind of duration?
24 minutes, 5 seconds?
For 2 hours past midnight?
For 2 hours after (clinical) event x
For 2 months after (clinical) event y
2 months cannot be technically represented in a duration, because 
month is not a stable time-definition. It is a Calendar definition.
It is therefor that most major programing languages have a Duration 
and a Calendar class.
Or you say that OpenEhr has no valid Duration-datatype, so always 
express Duration in an archetype (your way),
or say that OpenEhr has a valid Dv_Duration type, and do it right (I 
prefer this way),
or express months as if it is a stable time-indicator and ignore it 
is not (like it is now)


Those are the three possible ways to solve this problem, I think
I am curious to learn what the community will decide.

Bert




___
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: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?


On 21-03-18 13:57, Thomas Beale wrote:


although 'month' is not a scientific notion (it's not constant), we do 
treat it as a data type or unit in /social date time types/, which is 
what we are mostly dealing with, and what the types DvDuration, DvDate 
etc correspond to.


For scientific durations, use DvQuantity, and then you have a Real + 
units, e.g. 205ms, 89ns, 4.5min etc


So I think it is quite right to standardise these two notions in the 
RM, and also if we can, a standard model of 'time specification' which 
is the '3 times/day' kind of idea. We still don't have a good solution 
for this last one.




What is the problem with the Calendar type?
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

On 21-03-18 13:51, Thomas Beale wrote:

On 20/03/2018 23:33, A Verhees wrote:

One last remark.

There is in medical context need of a datatypes to express: "do this
one time a month, for example on a specific date".

But technically seen, this is not a duration, the maybe a need for
another datatype to express this.

Using the duration for this may be a handy shortcut in specs, but it
is not right. It is in fact misusing a datatype which does not
support this expression. The ISO string should also be changed
accordingly.

we don't really use Duration to represent 3 times / day. There are old
HL7 data types which we included in openEHR to do this, called GTS and
its children
<http://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_time_specification_package>.
It seems that noone uses these. THere have been many other attempts to
define either types or structures, like iCal and other
calendar-related structures. But I don't see a clear winner in terms
of standards.

THe medication archetypes solve it by using multiple fields, and in
Task Planning we had to create some new time specification types as
well - CLOCK_TIME, CALENDAR_TIME, and CUSTOMARY_TIME
<http://www.openehr.org/releases/PROC/latest/docs/task_planning/task_planning.html#_specifying_time>.

You can need Duration for many purposes
Which comes to mind. How long was the patient feeling bad? How long did
the patient sleep? How long was he staying in the hospital. These are
all Durations. How long was the pregnancy time, How much time is their
between two named phases of a heartbeat

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

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

No Duration type is a ISO8601 duration, ISO8601 is just a string 
representation of a duration. No programming language can, from its 
standard library safely express an ISO8601 in a class, because the 
ISO8601 is a combination of two types.
Unless you are wiling to have an uncertainty of 10%, you cannot express 
a month in a Duration type. For many software, this uncertainty is not 
acceptable. Maybe it is for medical purposes, but OpenEhr also has an 
Admin_Entry, and there this uncertainty is not always acceptable. How do 
you bill someone who was one month in a clinic? Make it 28 days or 31 days?

And the solution is easy, and it has advantages.

If we split the Dv_Duration in a Calendar part and in a Duration part, 
then both have their own merits. If you want to bill a stay of a month 
in a clinic, you express it by days (which are always 24 hours) P30D 
(represented by the Duration class) and if you want the patient to 
return every month, you can use the first part, P1M (represented by the 
Calendar class).

I don't think this is complex or requires complex algorithms, even 
opposite, it makes it more simple and more certain to process and all 
the troubles and bad feelings when converting a month to 30 days, and 
then find out it was 28 days, are gone. I think Joda was a complex 
solution for a simple problem.

Bert

On 21-03-18 13:47, Pieter Bos wrote:

There seems to be some confusion regarding the concept of a ISO8601 Duration. 
You can definitely define a duration of 2 months in ISO8601 Durations. It has 
separate fields for years, months, weeks, days, plus an optional time with 
hours, minutes and seconds. All these fields are optional and can all be 
combined. It cannot be fully modelled using a single nanosecond field - you 
would run into trouble with years, months, and even days, plus you cannot 
express for example a duration of 1 hour with no precision in the minutes and 
seconds fields mentioned. I think  
https://en.wikipedia.org/wiki/ISO_8601#Durations has a good explanation of the 
concept.

The golang Duration type in the time package is _not_ an ISO8601 duration, but 
just a duration in nanoseconds, explicitly omitting the definition of days. 
There are libraries available for golang that do model the full iso8601 
duration.

Of course, I agree that we should not have a far too big reference model. There 
is a point at which it no longer makes sense to add something to the reference 
model because it is better modelled in an archetype. But I think the concept of 
a duration can be very useful. You could use it to model the examples Gerard 
Freriks mentions for example:

- 24 minutes, 5 seconds can be modelled as a single Element with a DV_Duration value. The ISO8601 text representation of the dv_duration.value field would be PT24M5S.

- For 2 hours past midnight can be modeled with two Elements, for example a 
'duration after a specific time' archetype with two elements, one with  a 
DV_DURATION value and one a DV_TIME value, if that is what you want to express.
- A duration after a specific clinical event can be modelled as however you 
want to model the reference to the clinical event, plus a single DV_DURATION 
field. In the first example the  value field of the DV_DURATION would be P2M, 
the second PT2H

Say you want to model the duration after which to resume a specified daily 
activity after a specified clinical event . You could model it by creating an 
archetype with a reference to the clinical event, a model of a description of 
the activity, and then a single DV_DURATION field, describing the time between 
the event and the start of the daily activity.
The person entering the data with this archetype now has the freedom of 
choosing any detail level he or she wants - whether that is in terms of years, 
months, weeks, days, hours, minutes, seconds, or any combination of any of 
these terms.

And the nice thing is, you would use a standards based duration concept that is 
readily available in many off the shelf languages, libraries, serialization 
tools, UI components and databases, instead of defining your own. And it's 
already defined in the OpenEHR models, so you can start using it right away.

Regards,

Pieter Bos
Nedap Healthcare

On 21/03/2018, 12:25, "openEHR-technical on behalf of Bert Verhees" 
<openehr-technical-boun...@lists.openehr.org on behalf of bert.verh...@rosa.nl> wrote:

 On 21-03-18 10:50, GF wrote:

 > Does including Duration in the RM fit with the scope for the RM?
 >
 > Why do we have archetypes?
 > Why not include every thing in the RM?
 > Do we want the HL7v3 Reference Model as it existed many years ago and
 > that could not be inspected without a magnifying glass on a sheet of
 > paper that was 2 by 1 meters?
 >
 > Is there one kind of duration?
 > 24 minutes, 5 seconds?
 > For 2 hours past midnight?
 > For 2 hours after (c

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

That is true, but I think it would be good if it would find its way in the
RM, for two reasons
1) misusing the duration does not seem right, and I think the ISO string
representing a duration must change. That is, I know, a long way, so the
part before the 'T' should represent a calendar datatype, and the other
part should be a duration. It is also worth considering to split the
DV_DURATION type in the same way.
2) If it find its formal way in the RM libraries will support it also,
which will help implementers to do it the right way.

Bert

Op 20 mrt. 2018 23:48 schreef "Diego Boscá" <yamp...@gmail.com>:

> Nothing restricts you to create a "data type pattern"/specialized cluster
> that has exactly this semantics
>
> El mar., 20 mar. 2018 23:34, A Verhees <bert.verh...@rosa.nl> escribió:
>
>> One last remark.
>>
>> There is in medical context need of a datatypes to express: "do this one
>> time a month, for example on a specific date".
>>
>> But technically seen, this is not a duration, the maybe a need for
>> another datatype to express this.
>>
>> Using the duration for this may be a handy shortcut in specs, but it is
>> not right. It is in fact misusing a datatype which does not support this
>> expression. The ISO string should also be changed accordingly.
>>
>> Bert
>>
>> Op 20 mrt. 2018 23:24 schreef "A Verhees" <bert.verh...@rosa.nl>:
>>
>>> Now I come to think about it, I remember reading somewhere that
>>> conversion durations to number of years or months is no longer desired
>>> because years and months do not have always the same number of nanoseconds.
>>>
>>> Of course conversions to days and weeks is easy, although they are also
>>> not always the same, but that can be ignored, it is one second every few
>>> years.
>>>
>>> Op 20 mrt. 2018 23:08 schreef "A Verhees" <bert.verh...@rosa.nl>:
>>>
>>>> Now you say, you are right.
>>>>
>>>> The Java 8 duration is indeed diffrent, but you can still use the Joda
>>>> duration, or you can write your own duration class. In Golang the duration
>>>> class is also limited, it is build around nanoseconds, but I wrote my own
>>>> which is conform the OpenEhr specs, which was not that hard.
>>>>
>>>> https://golang.org/pkg/time/#Duration
>>>> https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html
>>>>
>>>> Maybe it is a good idea for the OpenEhr community to study the duration
>>>> type again to see why in two major programming languages there is another
>>>> approach build around nanoseconds and having  conversions to hours, etc.
>>>> Maybe there is another trend coming up. Maybe it is interesting to conform
>>>> to these trends
>>>>
>>>> Bert
>>>>
>>>> Op 20 mrt. 2018 21:06 schreef "Pablo Pazos" <pablo.pa...@cabolabs.com>:
>>>>
>>>> Thanks Thomas, will create the PR!
>>>>
>>>> Also will double check if the same happens with other types, but I
>>>> think the only "odd" one that might not be correct to assume, is the
>>>> Duration. For instance, Java 8 added the Duration as a base type, but it
>>>> only handles day to seconds duration expressions, year, month, week are not
>>>> supported. Each technology has it's own quirks :)
>>>>
>>>> On Tue, Mar 20, 2018 at 7:21 AM, Thomas Beale <thomas.be...@openehr.org
>>>> > wrote:
>>>>
>>>>>
>>>>>
>>>>> On 19/03/2018 22:25, Pablo Pazos wrote:
>>>>>
>>>>> Hi Thomas, the definition of DV_DURATION is clear to me :)
>>>>>
>>>>> The issue is on the 1.0.2 specs, I guess they used DV_DURATION in
>>>>> C_DURATION because the referenced Duration class in C_DURATION was not
>>>>> included on the specs. *This is the issue I'm pointing to, the
>>>>> missing class.*
>>>>>
>>>>>
>>>>> Right - the ADL/AOM 1.4 specs made the assumption that each primitive
>>>>> constrainer type i.e. C_INTEGER, C_STRING, C_DATE, C_DURATION etc,
>>>>> constrained a same- or similarly named primitive type like Integer, 
>>>>> String,
>>>>> Date, Duration etc that are assumed to be part of the technology
>>>>> environment. THey are normally part of the programming language, DB, or
>>>>> serialisati

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

A Calendar datatype.

Op 20 mrt. 2018 23:33 schreef "A Verhees" <bert.verh...@rosa.nl>:

> One last remark.
>
> There is in medical context need of a datatypes to express: "do this one
> time a month, for example on a specific date".
>
> But technically seen, this is not a duration, the maybe a need for another
> datatype to express this.
>
> Using the duration for this may be a handy shortcut in specs, but it is
> not right. It is in fact misusing a datatype which does not support this
> expression. The ISO string should also be changed accordingly.
>
> Bert
>
> Op 20 mrt. 2018 23:24 schreef "A Verhees" <bert.verh...@rosa.nl>:
>
>> Now I come to think about it, I remember reading somewhere that
>> conversion durations to number of years or months is no longer desired
>> because years and months do not have always the same number of nanoseconds.
>>
>> Of course conversions to days and weeks is easy, although they are also
>> not always the same, but that can be ignored, it is one second every few
>> years.
>>
>> Op 20 mrt. 2018 23:08 schreef "A Verhees" <bert.verh...@rosa.nl>:
>>
>>> Now you say, you are right.
>>>
>>> The Java 8 duration is indeed diffrent, but you can still use the Joda
>>> duration, or you can write your own duration class. In Golang the duration
>>> class is also limited, it is build around nanoseconds, but I wrote my own
>>> which is conform the OpenEhr specs, which was not that hard.
>>>
>>> https://golang.org/pkg/time/#Duration
>>> https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html
>>>
>>> Maybe it is a good idea for the OpenEhr community to study the duration
>>> type again to see why in two major programming languages there is another
>>> approach build around nanoseconds and having  conversions to hours, etc.
>>> Maybe there is another trend coming up. Maybe it is interesting to conform
>>> to these trends
>>>
>>> Bert
>>>
>>> Op 20 mrt. 2018 21:06 schreef "Pablo Pazos" <pablo.pa...@cabolabs.com>:
>>>
>>> Thanks Thomas, will create the PR!
>>>
>>> Also will double check if the same happens with other types, but I think
>>> the only "odd" one that might not be correct to assume, is the Duration.
>>> For instance, Java 8 added the Duration as a base type, but it only handles
>>> day to seconds duration expressions, year, month, week are not supported.
>>> Each technology has it's own quirks :)
>>>
>>> On Tue, Mar 20, 2018 at 7:21 AM, Thomas Beale <thomas.be...@openehr.org>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 19/03/2018 22:25, Pablo Pazos wrote:
>>>>
>>>> Hi Thomas, the definition of DV_DURATION is clear to me :)
>>>>
>>>> The issue is on the 1.0.2 specs, I guess they used DV_DURATION in
>>>> C_DURATION because the referenced Duration class in C_DURATION was not
>>>> included on the specs. *This is the issue I'm pointing to, the missing
>>>> class.*
>>>>
>>>>
>>>> Right - the ADL/AOM 1.4 specs made the assumption that each primitive
>>>> constrainer type i.e. C_INTEGER, C_STRING, C_DATE, C_DURATION etc,
>>>> constrained a same- or similarly named primitive type like Integer, String,
>>>> Date, Duration etc that are assumed to be part of the technology
>>>> environment. THey are normally part of the programming language, DB, or
>>>> serialisation formalisms.
>>>>
>>>> I think this probably was not as clear as it should have been in that
>>>> spec.
>>>>
>>>> In the AOM2/ADL2 specs, we have clarified this so that the same types
>>>> (C_INTEGER etc) now refer to types that are defined in the Foundation spec
>>>> of the BASE component.
>>>>
>>>>
>>>> Clarifying that on an errata addendum would help to avoid such
>>>> implementation mistakes, that are really caused by the missing information
>>>> on the spec + interpretation to fill the gap.
>>>>
>>>>
>>>> agree, we should do this - can you create a PR for this? Or add to an
>>>> existing PR.
>>>>
>>>>
>>>>
>>>> BTW, this is one case that I detected because I'm doing research for a
>>>> new course. There might be issues like this on other ar

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

Nanoseconds are probably not needed many times in medical context, but they
are not in the way of using them as seconds or minutes.

Op 20 mrt. 2018 23:27 schreef "Diego Boscá" <yamp...@gmail.com>:

> We can revisit all the types we want, but we shouldn't forget that types
> will be used for medical data, and maybe we don't really need nanosecond
> precision.
>
> El mar., 20 mar. 2018 23:09, A Verhees <bert.verh...@rosa.nl> escribió:
>
>> Now you say, you are right.
>>
>> The Java 8 duration is indeed diffrent, but you can still use the Joda
>> duration, or you can write your own duration class. In Golang the duration
>> class is also limited, it is build around nanoseconds, but I wrote my own
>> which is conform the OpenEhr specs, which was not that hard.
>>
>> https://golang.org/pkg/time/#Duration
>> https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html
>>
>> Maybe it is a good idea for the OpenEhr community to study the duration
>> type again to see why in two major programming languages there is another
>> approach build around nanoseconds and having  conversions to hours, etc.
>> Maybe there is another trend coming up. Maybe it is interesting to conform
>> to these trends
>>
>> Bert
>>
>> Op 20 mrt. 2018 21:06 schreef "Pablo Pazos" <pablo.pa...@cabolabs.com>:
>>
>> Thanks Thomas, will create the PR!
>>
>> Also will double check if the same happens with other types, but I think
>> the only "odd" one that might not be correct to assume, is the Duration.
>> For instance, Java 8 added the Duration as a base type, but it only handles
>> day to seconds duration expressions, year, month, week are not supported.
>> Each technology has it's own quirks :)
>>
>> On Tue, Mar 20, 2018 at 7:21 AM, Thomas Beale <thomas.be...@openehr.org>
>> wrote:
>>
>>>
>>>
>>> On 19/03/2018 22:25, Pablo Pazos wrote:
>>>
>>> Hi Thomas, the definition of DV_DURATION is clear to me :)
>>>
>>> The issue is on the 1.0.2 specs, I guess they used DV_DURATION in
>>> C_DURATION because the referenced Duration class in C_DURATION was not
>>> included on the specs. *This is the issue I'm pointing to, the missing
>>> class.*
>>>
>>>
>>> Right - the ADL/AOM 1.4 specs made the assumption that each primitive
>>> constrainer type i.e. C_INTEGER, C_STRING, C_DATE, C_DURATION etc,
>>> constrained a same- or similarly named primitive type like Integer, String,
>>> Date, Duration etc that are assumed to be part of the technology
>>> environment. THey are normally part of the programming language, DB, or
>>> serialisation formalisms.
>>>
>>> I think this probably was not as clear as it should have been in that
>>> spec.
>>>
>>> In the AOM2/ADL2 specs, we have clarified this so that the same types
>>> (C_INTEGER etc) now refer to types that are defined in the Foundation spec
>>> of the BASE component.
>>>
>>>
>>> Clarifying that on an errata addendum would help to avoid such
>>> implementation mistakes, that are really caused by the missing information
>>> on the spec + interpretation to fill the gap.
>>>
>>>
>>> agree, we should do this - can you create a PR for this? Or add to an
>>> existing PR.
>>>
>>>
>>>
>>> BTW, this is one case that I detected because I'm doing research for a
>>> new course. There might be issues like this on other areas of 1.0.2, I mean
>>> missing classes referenced from AOM or AOP. I didn't do a complete review
>>> of the specs.
>>>
>>> I would love to migrate everything to baseline spec and use AOM2, but I
>>> can't afford the cost right now. I'm sure others are on my same position.
>>>
>>>
>>> hopefully that will change soon, because ADL2 is more regular and
>>> simpler than ADL1.4 - the ADL2 OPT for example is much easier to process.
>>> I'd be interested to know what the real costs are and to see what we can do
>>> to make the transition simpler, because staying with ADL1.4 is limiting
>>> system functionality for the future.
>>>
>>>
>>> BTW tried to check if the issue is also on 1.0.3 but the link to support
>>> is broken http://openehr.org/RM/Release-1.0.3/support.html
>>>
>>>
>>> the page where you got that link
>>> <https://www.openehr.org/releases/RM/Release-1.0.3/docs/index> is now
>>> fixed.
>>>
>

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

One last remark.

There is in medical context need of a datatypes to express: "do this one
time a month, for example on a specific date".

But technically seen, this is not a duration, the maybe a need for another
datatype to express this.

Using the duration for this may be a handy shortcut in specs, but it is not
right. It is in fact misusing a datatype which does not support this
expression. The ISO string should also be changed accordingly.

Bert

Op 20 mrt. 2018 23:24 schreef "A Verhees" <bert.verh...@rosa.nl>:

> Now I come to think about it, I remember reading somewhere that conversion
> durations to number of years or months is no longer desired because years
> and months do not have always the same number of nanoseconds.
>
> Of course conversions to days and weeks is easy, although they are also
> not always the same, but that can be ignored, it is one second every few
> years.
>
> Op 20 mrt. 2018 23:08 schreef "A Verhees" <bert.verh...@rosa.nl>:
>
>> Now you say, you are right.
>>
>> The Java 8 duration is indeed diffrent, but you can still use the Joda
>> duration, or you can write your own duration class. In Golang the duration
>> class is also limited, it is build around nanoseconds, but I wrote my own
>> which is conform the OpenEhr specs, which was not that hard.
>>
>> https://golang.org/pkg/time/#Duration
>> https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html
>>
>> Maybe it is a good idea for the OpenEhr community to study the duration
>> type again to see why in two major programming languages there is another
>> approach build around nanoseconds and having  conversions to hours, etc.
>> Maybe there is another trend coming up. Maybe it is interesting to conform
>> to these trends
>>
>> Bert
>>
>> Op 20 mrt. 2018 21:06 schreef "Pablo Pazos" <pablo.pa...@cabolabs.com>:
>>
>> Thanks Thomas, will create the PR!
>>
>> Also will double check if the same happens with other types, but I think
>> the only "odd" one that might not be correct to assume, is the Duration.
>> For instance, Java 8 added the Duration as a base type, but it only handles
>> day to seconds duration expressions, year, month, week are not supported.
>> Each technology has it's own quirks :)
>>
>> On Tue, Mar 20, 2018 at 7:21 AM, Thomas Beale <thomas.be...@openehr.org>
>> wrote:
>>
>>>
>>>
>>> On 19/03/2018 22:25, Pablo Pazos wrote:
>>>
>>> Hi Thomas, the definition of DV_DURATION is clear to me :)
>>>
>>> The issue is on the 1.0.2 specs, I guess they used DV_DURATION in
>>> C_DURATION because the referenced Duration class in C_DURATION was not
>>> included on the specs. *This is the issue I'm pointing to, the missing
>>> class.*
>>>
>>>
>>> Right - the ADL/AOM 1.4 specs made the assumption that each primitive
>>> constrainer type i.e. C_INTEGER, C_STRING, C_DATE, C_DURATION etc,
>>> constrained a same- or similarly named primitive type like Integer, String,
>>> Date, Duration etc that are assumed to be part of the technology
>>> environment. THey are normally part of the programming language, DB, or
>>> serialisation formalisms.
>>>
>>> I think this probably was not as clear as it should have been in that
>>> spec.
>>>
>>> In the AOM2/ADL2 specs, we have clarified this so that the same types
>>> (C_INTEGER etc) now refer to types that are defined in the Foundation spec
>>> of the BASE component.
>>>
>>>
>>> Clarifying that on an errata addendum would help to avoid such
>>> implementation mistakes, that are really caused by the missing information
>>> on the spec + interpretation to fill the gap.
>>>
>>>
>>> agree, we should do this - can you create a PR for this? Or add to an
>>> existing PR.
>>>
>>>
>>>
>>> BTW, this is one case that I detected because I'm doing research for a
>>> new course. There might be issues like this on other areas of 1.0.2, I mean
>>> missing classes referenced from AOM or AOP. I didn't do a complete review
>>> of the specs.
>>>
>>> I would love to migrate everything to baseline spec and use AOM2, but I
>>> can't afford the cost right now. I'm sure others are on my same position.
>>>
>>>
>>> hopefully that will change soon, because ADL2 is more regular and
>>> simpler than ADL1.4 - the ADL2 OPT for example is much easier to process.
>>> I'd be interested to know w

Re: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?

Now I come to think about it, I remember reading somewhere that conversion
durations to number of years or months is no longer desired because years
and months do not have always the same number of nanoseconds.

Of course conversions to days and weeks is easy, although they are also not
always the same, but that can be ignored, it is one second every few years.

Op 20 mrt. 2018 23:08 schreef "A Verhees" <bert.verh...@rosa.nl>:

> Now you say, you are right.
>
> The Java 8 duration is indeed diffrent, but you can still use the Joda
> duration, or you can write your own duration class. In Golang the duration
> class is also limited, it is build around nanoseconds, but I wrote my own
> which is conform the OpenEhr specs, which was not that hard.
>
> https://golang.org/pkg/time/#Duration
> https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html
>
> Maybe it is a good idea for the OpenEhr community to study the duration
> type again to see why in two major programming languages there is another
> approach build around nanoseconds and having  conversions to hours, etc.
> Maybe there is another trend coming up. Maybe it is interesting to conform
> to these trends
>
> Bert
>
> Op 20 mrt. 2018 21:06 schreef "Pablo Pazos" <pablo.pa...@cabolabs.com>:
>
> Thanks Thomas, will create the PR!
>
> Also will double check if the same happens with other types, but I think
> the only "odd" one that might not be correct to assume, is the Duration.
> For instance, Java 8 added the Duration as a base type, but it only handles
> day to seconds duration expressions, year, month, week are not supported.
> Each technology has it's own quirks :)
>
> On Tue, Mar 20, 2018 at 7:21 AM, Thomas Beale <thomas.be...@openehr.org>
> wrote:
>
>>
>>
>> On 19/03/2018 22:25, Pablo Pazos wrote:
>>
>> Hi Thomas, the definition of DV_DURATION is clear to me :)
>>
>> The issue is on the 1.0.2 specs, I guess they used DV_DURATION in
>> C_DURATION because the referenced Duration class in C_DURATION was not
>> included on the specs. *This is the issue I'm pointing to, the missing
>> class.*
>>
>>
>> Right - the ADL/AOM 1.4 specs made the assumption that each primitive
>> constrainer type i.e. C_INTEGER, C_STRING, C_DATE, C_DURATION etc,
>> constrained a same- or similarly named primitive type like Integer, String,
>> Date, Duration etc that are assumed to be part of the technology
>> environment. THey are normally part of the programming language, DB, or
>> serialisation formalisms.
>>
>> I think this probably was not as clear as it should have been in that
>> spec.
>>
>> In the AOM2/ADL2 specs, we have clarified this so that the same types
>> (C_INTEGER etc) now refer to types that are defined in the Foundation spec
>> of the BASE component.
>>
>>
>> Clarifying that on an errata addendum would help to avoid such
>> implementation mistakes, that are really caused by the missing information
>> on the spec + interpretation to fill the gap.
>>
>>
>> agree, we should do this - can you create a PR for this? Or add to an
>> existing PR.
>>
>>
>>
>> BTW, this is one case that I detected because I'm doing research for a
>> new course. There might be issues like this on other areas of 1.0.2, I mean
>> missing classes referenced from AOM or AOP. I didn't do a complete review
>> of the specs.
>>
>> I would love to migrate everything to baseline spec and use AOM2, but I
>> can't afford the cost right now. I'm sure others are on my same position.
>>
>>
>> hopefully that will change soon, because ADL2 is more regular and simpler
>> than ADL1.4 - the ADL2 OPT for example is much easier to process. I'd be
>> interested to know what the real costs are and to see what we can do to
>> make the transition simpler, because staying with ADL1.4 is limiting system
>> functionality for the future.
>>
>>
>> BTW tried to check if the issue is also on 1.0.3 but the link to support
>> is broken http://openehr.org/RM/Release-1.0.3/support.html
>>
>>
>> the page where you got that link
>> <https://www.openehr.org/releases/RM/Release-1.0.3/docs/index> is now
>> fixed.
>>
>> - thomas
>>
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_
>> lists.openehr.org
>>
>
>
>
> --
> Ing. Pablo Pazos Gutiérrez
> pablo.pa...@cabolabs.com
> +598 99 043 145 <+598%2099%20043%20145>
> skype: cabolabs
> <http://cabolabs.com/>
> http://www.cabolabs.com
> https://cloudehrserver.com
> Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>
> ___
> 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: Should Duration class used in AOM 1.0.2 be ISO8601_DURATION from support specs?