from:"Bert Verhees"

RE: Archetype modelling pattern for Physical examination findings

2019-03-06 Thread Bert Verhees

Very important, I see as major advantage that gives predictability for 
archetypepaths which is necessary for wild carding AQL queries on unknown 
archetypes or groups of archetypes on different observations. In the field of 
observations this is part of a major step forwards. Researchers and software 
developers, also, but not only in AI, will profit from this. 

The growth towards pattern was already visible during last several years, and I 
am glad that the desire to have this, and architecture howto do it,  has become 
available for the public. I hope modelers will use this, even in moments when 
without pattern seems more effective on a single archetype, they still will 
choose for the greater good of patterned information. 

Congratulations for the CKM team for this major step forwards. 
Bert

Sent from my Xperia™ by Sony smartphone

 Heather Leslie wrote 

>Hi everyone,
>
>The CKM editors have been gradually refining our views on how to model 
>Physical examination findings for many years now. There have been many hours 
>wasted exploring options that have had dead ends. We'd like to prevent others 
>having the same experience by sharing and publishing an agreed pattern and we 
>feel that we have one ready for broader consumption.
>
>We clearly needed to find a solution that works from a modelling point of view 
>ensuring that the clinically diverse requirements are catered for, as well as 
>the needs of implementers for querying etc.
>
>I have developed a page on the wiki to try to explain our proposal and provide 
>some examples - 
>https://openehr.atlassian.net/wiki/spaces/healthmod/pages/380993560/Proposal+-+Physical+examination+findings+pattern
>
>Comments welcome, probably best if you add them to the wiki page, please.
>
>Regards
>
>Heather
>
>Dr Heather Leslie
>MB BS, FRACGP, FACHI, GAICD
>M +61 418 966 670
>Skype: heatherleslie
>Twitter: @atomicainfo, @clinicalmodels & @omowizard
>www.atomicainformatics.com
>[cid:image001.jpg@01D4D4EB.68E10F10]
>
>
>___
>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: serialization syntax of openEHR instance data

2019-02-22 Thread Bert Verhees


On 22-02-19 12:27, Georg Fette wrote:

Hello,
Thank you all. The .xsds are already very useful. And the Toolkit also 
looks beneficial for what I want to do.


The toolkit is great, very impressive work.

Also, I found the API-exporer from Marand in which you can test and look 
at API's


https://www.ehrscape.com/api-explorer.html

Both sides together should give you enough tooling about how OpenEhr is 
supposed to work in the technical details.


Bert





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

Re: serialization syntax of openEHR instance data

2019-02-22 Thread Bert Verhees

Dear Georg, my answer is a bit cumbersome, sorry for that, but it is the best I 
can give with not too much effort. 

Go to one of the Marand websites, there is (at least it was, a few years ago, 
last time I looked) their API published in a kind of Open API format, which 
gives you opportunity to experiment with the API and thus also see the JSON 
datasets. 

Best regard
Bert 

Sent from my Xperia™ by Sony smartphone

 Bert Verhees wrote 

>The question asked by George Fette is that he wants to see an example of an 
>OpenEhr dataset in XML or JSON  containing demographics and commonly used 
>archetypes.
>
>Best regards
>Bert
>
>Sent from my Xperia™ by Sony smartphone
>
> Pablo Pazos wrote 
>
>>Adding to Thomas comments,
>>
>>1. Yes, XML XSDs should be the source of truth here
>>2. You can use the openEHR Toolkit to generate instances in XML from an OPT
>>http://server001.cloudehrserver.com/cot/
>>
>>That helps testing and verifying formats.
>>
>>On Thu, Feb 21, 2019 at 5:45 AM Thomas Beale 
>>wrote:
>>
>>> You may want to look at the XSDs here on Github
>>> <https://github.com/openEHR/specifications-ITS-XML/tree/master/components>
>>> and JSON schemas (emerging) here
>>> <https://github.com/openEHR/specifications-ITS-JSON>.
>>> On 21/02/2019 08:14, Georg Fette wrote:
>>>
>>> Hello,
>>> Is there a documentation of the syntax how openEHR EHR data is serialized
>>> ? I would be interested in a concrete example of an EHR-API-GET-call and
>>> the returned String in XML or JSON which can be used as transfer medium
>>> between applications or as a storage format. It would be beneficial if the
>>> example EHR would contain some commonly used archetypes and some usual
>>> demographics data.
>>> I have taken a look at
>>> https://openehr.github.io/specifications-ITS-REST/ehr.html and at the
>>> "EHR Extract Information Model" but I haven't found something that satified
>>> me in this matter.
>>> Greeting
>>> Georg
>>>
>>> --
>>> 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
>>>
>>
>>
>>-- 
>>*Ing. Pablo Pazos Gutiérrez*
>>pablo.pa...@cabolabs.com
>>+598 99 043 145
>>skype: cabolabs
>>Subscribe to our newsletter <http://eepurl.com/b_w_tj>
>><https://cabolabs.com/>
>>http://www.cabolabs.com
>>https://cloudehrserver.com
>>
>>___
>>openEHR-technical mailing list
>>openEHR-technical@lists.openehr.org
>>http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: serialization syntax of openEHR instance data

2019-02-22 Thread Bert Verhees

The question asked by George Fette is that he wants to see an example of an 
OpenEhr dataset in XML or JSON  containing demographics and commonly used 
archetypes.

Best regards
Bert

Sent from my Xperia™ by Sony smartphone

 Pablo Pazos wrote 

>Adding to Thomas comments,
>
>1. Yes, XML XSDs should be the source of truth here
>2. You can use the openEHR Toolkit to generate instances in XML from an OPT
>http://server001.cloudehrserver.com/cot/
>
>That helps testing and verifying formats.
>
>On Thu, Feb 21, 2019 at 5:45 AM Thomas Beale 
>wrote:
>
>> You may want to look at the XSDs here on Github
>> 
>> and JSON schemas (emerging) here
>> .
>> On 21/02/2019 08:14, Georg Fette wrote:
>>
>> Hello,
>> Is there a documentation of the syntax how openEHR EHR data is serialized
>> ? I would be interested in a concrete example of an EHR-API-GET-call and
>> the returned String in XML or JSON which can be used as transfer medium
>> between applications or as a storage format. It would be beneficial if the
>> example EHR would contain some commonly used archetypes and some usual
>> demographics data.
>> I have taken a look at
>> https://openehr.github.io/specifications-ITS-REST/ehr.html and at the
>> "EHR Extract Information Model" but I haven't found something that satified
>> me in this matter.
>> Greeting
>> Georg
>>
>> --
>> Thomas Beale
>> Principal, Ars Semantica 
>> Consultant, ABD Project, Intermountain Healthcare
>> 
>> Management Board, Specifications Program Lead, openEHR Foundation
>> 
>> Chartered IT Professional Fellow, BCS, British Computer Society
>> 
>> Health IT blog  | Culture blog
>>  | The Objective Stance
>> 
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>
>
>-- 
>*Ing. Pablo Pazos Gutiérrez*
>pablo.pa...@cabolabs.com
>+598 99 043 145
>skype: cabolabs
>Subscribe to our newsletter 
>
>http://www.cabolabs.com
>https://cloudehrserver.com
>
>___
>openEHR-technical mailing list
>openEHR-technical@lists.openehr.org
>http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
___
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

2019-02-16 Thread Bert 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

2019-02-16 Thread Bert Verhees


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

2019-02-16 Thread Bert Verhees


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

2019-02-16 Thread Bert Verhees

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

2019-02-15 Thread Bert Verhees

> 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

2019-02-15 Thread 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 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

2019-02-15 Thread Bert Verhees

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

2019-02-15 Thread Bert Verhees

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

2019-02-15 Thread Bert Verhees

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 ?

2018-12-12 Thread Bert Verhees


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 ?

2018-12-12 Thread Bert Verhees


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 ?

2018-12-12 Thread Bert Verhees


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 ?

2018-12-12 Thread Bert Verhees


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

2018-11-12 Thread Bert Verhees


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

2018-11-12 Thread Bert Verhees


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

2018-11-12 Thread Bert Verhees


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

2018-11-12 Thread Bert Verhees

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.

2018-09-03 Thread Bert Verhees

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.

2018-09-03 Thread Bert Verhees

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.

2018-09-03 Thread Bert Verhees

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.

2018-09-03 Thread Bert Verhees

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

2018-07-17 Thread Bert Verhees


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

2018-07-17 Thread Bert Verhees


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

2018-07-17 Thread Bert Verhees


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

2018-07-17 Thread Bert Verhees

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

2018-07-16 Thread Bert Verhees


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

2018-07-16 Thread Bert Verhees


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

2018-07-16 Thread Bert Verhees


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

2018-07-16 Thread Bert Verhees


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

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




Op do 29 mrt. 2018 02:39 schreef Pablo Pazos >:

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

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


___
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

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

2018-03-21 Thread Bert Verhees


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?

2018-03-21 Thread Bert Verhees

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?

2018-03-21 Thread Bert Verhees


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?

2018-03-21 Thread Bert Verhees

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?

2018-03-21 Thread Bert Verhees


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?

2018-03-21 Thread Bert Verhees


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


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?

2018-03-21 Thread Bert Verhees

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?

2018-03-19 Thread Bert Verhees


On 19-03-18 16:16, Thomas Beale wrote:



On 19/03/2018 08:57, GF wrote:

Again my thoughts

Duration is not a Data Type in many computer languages.
So we need to model it in an Archetype (Chairos)


that's true, but in databases and XML it is, and it is mostly treated 
like a primitive data type - i.e. a non-identified, instance-only type 
- in most language libraries. Note - here I am talking about a 
primitive type 'Duration' (also Iso8601_duration), not types like 
DV_DURATION. For AOM2, we treat it and the other date/time primitives 
as proper primitive types, also Uri, etc, and it makes life much easier.


- thomas

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



My opinions:

First: I agree with the distinction in datatypes between AOM and RM. The 
AOM should live as much as possible independent from the RM (I prefer 
completely independent), the RM should only deal with data-constructions 
and datatypes to describe target-data in.


Second: The archetype should be independent from the used computer 
language to build the AOM in. In many languages Duration is a valid 
datatype.


Java has it, Golang has it, C++ has it. And if it is not in a 
programming language, that language should be extended by a library 
which delivers the datatype.


Best regards

Bert


___
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-13 Thread Bert Verhees


On 13-03-18 17:45, Philippe Ameline wrote:
in my own terms, it means that it is not the proper component for 
modern applications.


Wasn't it Voltaire who said that the best is the enemy of the good?




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

Re: Templates for application form development

2018-03-13 Thread Bert Verhees


Hi contributors on this,

I am sorry not contributing so much, it is not my piece of cake to work 
on defining standards, I like better using them.


So I like to express that I am very grateful for the work which is being 
done in this context and the way it is being done.

I think that it will be a big step forwards for OpenEhr.

Best regards
Bert Verhees


On 13-03-18 00:04, Erik Sundvall wrote:

Hi!

I have also updated the 
https://openehr.atlassian.net/wiki/spaces/spec/pages/175276035/Application+Data-sets 
wikipage to include


  * references to some previous GUI discussions and
  * Region Östergötlands current use case and initial
Ethercis-OPT-introspector+Angular-based design plans (See heading
"OPT form renderer needed for pilot testing of surgery process
supporting system" near the end of the page.

Best regards,
Erik Sundvall
Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 
55 (or 010-1036252 in Sweden)
Region Östergötland: erik.sundv...@regionostergotland.se 
<mailto:erik.sundv...@regionostergotland.se> (previously lio.se 
<http://lio.se>) http://www.regionostergotland.se/cmit/
Linköping University:erik.sundv...@liu.se 
<mailto:erik.sundv...@liu.se>, http://www.imt.liu.se/~erisu/ 
<http://www.imt.liu.se/%7Eerisu/>


On Mon, Mar 12, 2018 at 11:48 PM, Pablo Pazos 
<pablo.pa...@cabolabs.com <mailto:pablo.pa...@cabolabs.com>> wrote:


Thanks Thomas, I added a paragraph about the UI generation modes
at the end, I forgot to mention that yesterday.

On Mon, Mar 12, 2018 at 9:40 AM, Thomas Beale
<thomas.be...@openehr.org <mailto:thomas.be...@openehr.org>> wrote:

Pablo,

Good work - I've included a reference to this doc in the
original wiki page

<https://openehr.atlassian.net/wiki/spaces/spec/pages/175276035/Application+Data-sets>,
and added a few ideas about how to use it. It is very close to
what I was thinking of.

- thomas


On 12/03/2018 07:31, Pablo Pazos wrote:

Hi all,

I manage to translate / update part of the work we did some
years ago in terms of UI definition and generation for the
openEHR stack.

Here is the doc, feedback is very welcome!


https://docs.google.com/document/d/13rJMLoW-2tJtl9ejKAIkJbWe-_T9H6UMsGNkiZoU7Iw/edit?usp=sharing

<https://docs.google.com/document/d/13rJMLoW-2tJtl9ejKAIkJbWe-_T9H6UMsGNkiZoU7Iw/edit?usp=sharing>




-- 
Thomas Beale

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

___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
<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 <tel:+598%2099%20043%20145>
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

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

2018-03-01 Thread Bert Verhees


On 01-03-18 12:12, Diego Boscá wrote:
Assuming there is a service that provides the given value for a given 
identified range (based on the parameters you provide like sex, age, 
race... ) it would be allowing kind of namespaces that have defined 
operations. This would also allow easy querying of external 
terminologies, public health queries (average/max/min of X in 
population that has Y, Z, W properties), etc.


Exactly, it could bring in information from external services in the AQL 
query, for example, a SNOMED hierarchy could be used in an AQL query.


Bert

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

Re: Setting thresholds

2018-03-01 Thread Bert Verhees


On 01-03-18 12:01, Diego Boscá wrote:
I believe that we need a way in standard AQL to call to arbitrary 
external services, this seems like another use case for that \


I agree!

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

Re: Announcing Archie version 0.4

2018-02-23 Thread Bert Verhees


On 23-02-18 17:17, Thomas Beale wrote:


On 23/02/2018 15:36, Pieter Bos wrote:
For microservices with enough traffic, or for devices with limited 
processing power or limited bandwidth, a binary encoding makes sense. 
However, GRPC would not be my first choice for OpenEHR - you would 
have to find a way to map all the inheritance in the OpenEHR model to 
protocol buffers.




actually, you don't need to do that, you can just map to protobuf from 
inheritance-flattened form of the model classes. That can easily be 
generated from a model - UML tools, do it, BMM supports it, I think it 
should also be easy via Java reflection.


Good idea, there is some information on the subject on internet.

Bert

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

Re: Announcing Archie version 0.4

2018-02-23 Thread Bert Verhees


On 23-02-18 16:36, Pieter Bos wrote:

you would have to find a way to map all the inheritance in the OpenEHR model to 
protocol buffers.
For Java I found this web-page which explains how to do it. It is about 
a class with one nested class


https://developers.google.com/protocol-buffers/docs/javatutorial




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

Re: Announcing Archie version 0.4

2018-02-23 Thread Bert Verhees


On 23-02-18 14:37, Pieter Bos wrote:

A small amount of JavaScript working with Json from a backend works very well 
for us.

You don’t always need explicit class definitions. it does require a different 
programming style than a more object oriented language.


Thomas has a point,

JSON/REST is not efficient,
- text takes a lot of bandwidth, an Integer f.e. 3,000,000,000 is only 4 
bytes in binary but 10 bytes in text,
- the translating from datatypes to text and back again takes a lot of 
CPU cycles,
- semantical is REST not fitted for many function-calls, HTTP-errors are 
misused for functional error-codes
- the http-protocol with all the headers is not efficient and has 
unnecessary overload
- REST is not error or type safe, you can send anything to a 
restservice, it processes the whole request-headers, and then looks if 
the parameters are sufficient in number and in type


Check this, it is a good explanation (if you have time for that, it 
hardly handles about Go):

https://www.youtube.com/watch?v=J-NTfvYL_OE

The question is only of a license-restricted product as ICE is the 
answer to this problem
For microservices GRPC works very well, it has a performance of 
sometimes 100* the performance of rest, it supports also bi-directional 
streaming, and it is safe, because the interface-code is generated.


There are some promising projects for GRPC in browsers which support 
HTTP/2 (this are all browsers in their latest versions)

I did not test it, but I will, in a few weeks in a project I am working on.
https://github.com/improbable-eng/grpc-web

Bert



Regards,

Pieter Bos

Op 23 feb. 2018 om 14:21 heeft Bert Verhees 
<bert.verh...@rosa.nl<mailto:bert.verh...@rosa.nl>> het volgende geschreven:

The problem with Ice is that it is not open source licensed when used in a non 
GPLv2 product.
Another problem is that they do not publish the price of a commercial license.

That are restrictions that cause many programmers not to use it.

https://zeroc.com/licensing


On 23-02-18 13:59, Thomas Beale wrote:

Belated thought on this topic: a much better way to connect a JavaScript front end 
with a Java back end, or any similar combination, would be with a binary RPC protocol 
like ICE<https://zeroc.com/products/ice>, that comes with tools to make it all 
work.

- thomas

On 05/02/2018 22:04, Thomas Beale wrote:


yes, JS = javascript, TypeScript etc. No, nothing to do with Java of course. 
Just that JS/TS are the languages that seem to be popular for web app 
development these days, and Java for the back-end. The connection between front 
and back-end that people seem to prefer these days is REST APIs, which both 
Java and JS can do easily enough.

- thomas

On 03/02/2018 07:56, Peter Gummer wrote:
On 1 Feb 2018, at 05:13, Thomas Beale 
<thomas.be...@openehr.org<mailto:thomas.be...@openehr.org>> wrote:

... But the main interest is that we will be able to build new tools such as a 
Java/JS replacement for the ADL Workbench, and of course things like a 
high-quality, BMM-driven runtime archetype validating kernel for EHR systems, 
workflow implementations and many other components.

Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand how Archie 
(written in Java, disappointingly) would enable JavaScript implementations. 
JavaScript has nothing in common with Java (apart from the name).

Peter




___
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: Announcing Archie version 0.4

2018-02-23 Thread Bert Verhees

The problem with Ice is that it is not open source licensed when used in 
a non GPLv2 product.
Another problem is that they do not publish the price of a commercial 
license.


That are restrictions that cause many programmers not to use it.

https://zeroc.com/licensing


On 23-02-18 13:59, Thomas Beale wrote:


Belated thought on this topic: a much better way to connect a 
JavaScript front end with a Java back end, or any similar combination, 
would be with a binary RPC protocol like ICE 
, that comes with tools to make it all 
work.


- thomas

On 05/02/2018 22:04, Thomas Beale wrote:



yes, JS = javascript, TypeScript etc. No, nothing to do with Java of 
course. Just that JS/TS are the languages that seem to be popular for 
web app development these days, and Java for the back-end. The 
connection between front and back-end that people seem to prefer 
these days is REST APIs, which both Java and JS can do easily enough.


- thomas


On 03/02/2018 07:56, Peter Gummer wrote:
On 1 Feb 2018, at 05:13, Thomas Beale > wrote:


... But the main interest is that we will be able to build new 
tools such as a Java/JS replacement for the ADL Workbench, and of 
course things like a high-quality, BMM-driven runtime archetype 
validating kernel for EHR systems, workflow implementations and 
many other components.




Hi Thomas, does “JS” stand for JavaScript? If so, I don’t understand 
how Archie (written in Java, disappointingly) would enable 
JavaScript implementations. JavaScript has nothing in common with 
Java (apart from the name).


Peter




___
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: Templates for application form development

2018-02-21 Thread Bert Verhees


On 20-02-18 20:09, Thomas Beale wrote:


The terminology service also has dependencies to rm data types, only 
because of codephrase. Wouldn't it be possible to avoid that?


Yes, there is a new class TERMINOLOGY_CODE that is used in BASE 
instead of CODE_PHRASE; eventually, the RM should just use that. If 
you found any use of CODE_PHRASE in BASE, please let us know.


This is of course a good thing.


But now the question, how do I know which definition to use.

I always looked at this URL: 
http://www.openehr.org/programs/specification/workingbaseline


There I found "Support", which brings me to:

http://www.openehr.org/releases/RM/latest/docs/support/support.html

In that, there is CODE_PHRASE still used in TERMINOLOGY_ACCESS.


Now I read that there is a new class in BASE, I found the link: 
http://www.openehr.org/releases/BASE/latest/docs/index


And I found Terminology_Code: 
http://www.openehr.org/releases/BASE/latest/docs/base_types/base_types.html#_terminology_code_class


Which is a real improvement, exactly what I was hoping for, it did not 
only remove the CODE_PHRASE from datatypes, but also TERMINOLOGY_ID 
class from SUPPORT


It has a property/field which is named terminology_id and is of type string


Is this what is going to be the new standard?

And when will this be like that?


When looking further, I also see that there is still a TERMINOLOGY_ID 
class in that document which is the old support terminology which is 
derived from OBJECT_ID


http://www.openehr.org/releases/BASE/latest/docs/base_types/base_types.html#_terminology_id_class


Is this confusing, or am I missing something stupid? Am I the only 
person asking this kind of questions? If yes, where do others get their 
information from?


Please help me, because, I think, this is very important.


Thanks

Bert


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

Re: Templates for application form development

2018-02-20 Thread Bert Verhees

I must have missed new developments, I am still working with RM 1.0.3 
which, I was thinking, is the production version


My remarks were for that version, and for my idea, there were some 
inconveniences in it.


But I will study the new RM, and if I find some similar inconveniences, 
I report them.


This is a bit another subject, but I explain it anyway, because last 
weekend, I was not satisfied about my emails

Please let me explain why it is an important problem to me.

Maven (Java dependency tool) gets grumpy about circular library 
references, and the Golang compiler does accept circular package 
references and restricts using circular struct references.
C++ does not accept circular class references, but can be worked around 
in a tricky way.


Circular references

The Dependency Rule says that source code dependencies can only point 
inwards. Nothing in an inner circle can know anything at all about 
something in an outer circle. In particular, the name of something 
declared in an outer circle must not be mentioned by the code in an 
inner circle. That includes, functions, classes. variables, or any other 
named software entity. As you move inwards the level of abstraction 
increases. The outermost circle is low level concrete detail. As you 
move inwards the software grows more abstract, and encapsulates higher 
level policies.


Robert C Martin.

Terminologyservice needs codephrase, and codeprase is part of the 
datatypes, dvtext (also datatype) needs terminologyservice (in 
constructor). (circular reference)
Other datatypes, for example, dvtext also need a ready compiled 
terminologyservice and codephrase for checking the charset and language 
in the constructor
This situation makes it impossible to separate the terminologyservice 
from the datatypes, although they have no similar abstraction level
In OpenEhr this is solved by using an interface of terminologyService 
inside the support-part, and that would be a good solution if the 
interface did not have the codephrase also in its declarations.
So it did not solve it the violation of the dependency rule, but it 
makes it compilable.


So it is a problem, and causes dirty code to solve. The solution is 
simple. Make CodePhrase a part of TerminologyService and remove it from 
datatypes. Then all classes which need code-phrase have to link in 
terminologyservice, but terminology can be compiled independently from 
other classes


The most inner circle of the dependencies should be a group 
libraries/classes which do not need each other by the route of an outer 
circle. The most inner group should be AOM, TerminologyService, EHR-RM, 
around that should be the Support, and around that should be the 
datatypes. Then there would be no problem, the datatypes can be linked 
against every library and will never cause a circular reference.


Best regards
Bert

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

Re: Templates for application form development

2018-02-19 Thread Bert Verhees

Often Spanish is not always a big problem, let us try drag through 
Google translate to make it al readable


Bert


On 19-02-18 17:37, David Moner wrote:
We also have a Final Degree Project where a student made a proposal 
for a Visual Template Model. It's from 2012, for ISO 13606, and also 
in Spanish, but the main idea probably remains the same :-)


I've been always in favor of having a third layer for visualization 
purposes that defines some of the expected behaviors and the visual 
aspect. As Erik said, this is not about reinventing what the existing 
UI frameworks can do, but to have a way of instructing them on how to 
show the information on screen.


2018-02-18 19:57 GMT+01:00 Pablo Pazos >:


I have a pdf spec in Spanish, this was a university project to
have platform independent GUI definitions based on opts, while
creating technology specific GUI generators for data entry and
display. I mentioned this a while ago on the lists but catched not
much attention.

Need to do a little translation work :)


On Feb 18, 2018 7:51 AM, "Thomas Beale" > wrote:



On 17/02/2018 20:11, Pablo Pazos wrote:

I think SET has a lot of applications,
including result sets. Of course that should interior from
LOCATABLE to be archetypable.

I'm not sure on the types associated with the UI. I have a
specification for UITenplates that includes some of that,
I can share it :)


I think any existing UI/template specification / app modelling
would be useful to share - possibly on the wiki - let me know
if you need a page there.

My aim would be to get closer to an IDE application building
tool for clinical people to at least build a POC application
that works, something like Balsamiq but with real data
connections built in. Marand's EhrExplorer does some of this,
and it would also be useful to extract some of the semantics
of that tool into a standard specification to support this
kind of thing.

- thomas



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


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





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


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






--
David Moner Cano

Web: http://www.linkedin.com/in/davidmoner
Twitter: @davidmoner
Skype: davidmoner


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



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

Re: Templates for application form development

2018-02-19 Thread Bert Verhees

It can be that Compositions appear in a single GUI-form (in GP 
applications this happens regularly), but there is still no need to to 
show them from a single template. That can be up to the GUI-designer, he 
can use HTML-features to handle one or more entries in a single 
GUI-view. Having the entries offered to the GUI-developer separated from 
the composition offers all the flexibility the GUI-developer needs.


He can show a complete composition by connecting GUI-blocks on 
client-level, he can show history-lists of medications or observations 
without composition context, what ever is desired.


Bert


On 19-02-18 12:07, Thomas Beale wrote:



note that a key problem I want to address is that templates based on 
COMPOSITIONs don't really make sense as models of data 
retrieval/display forms - they are really only useful for data capture 
forms (or messages, or documents), because COMPOSITION is a container 
for committing data to the EHR.


Displaying data is a different question - it may be EHR data, it may 
be demographic data, and it may be something else entirely. So the 
data items we want to mention in templates are mostly of ENTRY level, 
and will be the results of queries; the relevant queries could be 
included in such templates.


So the starting point for many forms won't be a COMPOSITION - it is 
instead a different logical container that groups data that result 
from one or more queries, into a 'use group', i.e the group of data 
items intended to be visualised or used as a report etc.


One problem today is that people trying to define screens for visual 
applications are forced (more or less) to create templates starting 
with COMPOSITIONs, which is incorrect; my impression is that such 
templates are only used for data capture and that other display forms 
are modelled in various non-standard ways, or not at all.


I think annotations (based on paths) will be useful, but I not 
completely adequate to achieved what is needed.


- thomas


On 19/02/2018 07:49, Erik Sundvall wrote:

Hi!

I agree that in many use-cases it is better to have a separate 
template intended for GUI/application hints overlayed on a "normal" 
data content definition template. (Quick experimentation may be an 
exception.)


That is why I added "layers of templates" in my previous comment - 
sorry for not explaining in detail. So a GUI-hint-annotated template 
based on another "normal" content aggregation/constraint-focused 
template would be a way to do it. I guess the effect in a resulting 
operational template (OPT) is essentially the same no matter how many 
layers of templates you choose to work with, right? So a 
form/GUI-renderer based on OPTs does not care how you layer the 
design, but your maintenance headaches might be affected if not 
separating things at design time.


I agree with Diego and Bert and suggest starting experimenting in the 
AM end (for example using annotations with GUI-hints in templates) 
and see how far that takes us, before possibly considering extending 
the RM (or whatever *M).


Annotations do not require any changes to AM or RM, the mechanism is 
already defined in the specifications. Conventions regarding patterns 
or prefixes in annotation keys and/or annotation values will likely 
give enough to start with.


A (not so very thought through yet) possible example of annotation 
use for application building is available in picture 40 (and 
supported by picture 36 in
https://drive.google.com/file/d/1kxXeJMe0ltfLlchGA0Lm8mfOD-PQDLFy/view?usp=sharing 



//Erik

mån 19 feb. 2018 kl. 10:22 skrev Bert Verhees <bert.verh...@rosa.nl 
<mailto:bert.verh...@rosa.nl>>:


On 18-02-18 23:09, GF wrote:
> Is it an idea to annotate nodes with instructions for display.

Personally I think having special templates/archetypes for display is
better. Templates are create per purpose, and mixing purposes in a
single template does  seem good idea to me


___
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


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

Re: Templates for application form development

2018-02-19 Thread Bert Verhees


On 19-02-18 10:21, Diego Boscá wrote:
Personally I would prefer if no visualization attributes ended up in 
the EHR RM, but I'm fine if we want to create an additional RM to 
handle visualization (and we create templates of that model that point 
to the EHR model)


I agree on this!

(again sloppy English in my previous message, this time changing the 
meaning, I changed the quote below, I am awake now, will not happen 
again, excuse me)




2018-02-19 10:15 GMT+01:00 Bert Verhees <bert.verh...@rosa.nl 
<mailto:bert.verh...@rosa.nl>>:


On 18-02-18 23:09, GF wrote:

Is it an idea to annotate nodes with instructions for display.


Personally I think having special templates/archetypes for display
is better. Templates are create*d* per purpose, and mixing
purposes in a single template does *no**t* seem good idea to me



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

Re: Templates for application form development

2018-02-19 Thread Bert Verhees


On 18-02-18 23:09, GF wrote:

Is it an idea to annotate nodes with instructions for display.


Personally I think having special templates/archetypes for display is 
better. Templates are create per purpose, and mixing purposes in a 
single template does  seem good idea to me



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

Re: Templates for application form development

2018-02-18 Thread Bert Verhees





Best regards
Bert


And sorry for the sloppy English (when reading back), on Sundays it is 
worse then on weekdays when I am in working mode. But I think my message 
is still understandable, so, have a nice Sunday-evening.

;-)

Bert

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

Re: Templates for application form development

2018-02-18 Thread Bert Verhees


On 18-02-18 16:55, Thomas Beale wrote:



On 18/02/2018 11:16, Erik Sundvall wrote:


When designing this, perhaps some (2-5) existing currently popular 
GUI frameworks could be initial targets for output from the process, 
and the selection could be updated over time. Perhaps for example 
https://angular.io/ and https://reactjs.org/ are two starting 
candidates for experimentation? (Both have partially declarative 
design, but other suggestions are of course welcome) Then mechanisms 
in those platforms could be reused rather than reinvented.


I think I must have been run out of credit, since my emails yesterday. 
But still I take my chance.


I must warn, Angular is a very complex environment, with much more 
functionality then just showing GUI's. I am afraid you load a lot of 
complexity which will not pay out. By the way, I thought that Marand 
still uses AngularJS, I don't know how I got this information, but check 
it before deciding for it. AngularJS which is the previous version, and 
is in fact not further developed and not maintained.
This for generating Angular code or ReactJS code (which is even more 
complex because it is a whole different paradigm)


There are many disadvantages of using a complex framework.
The disadvantage of using Angular or React is that it is not something 
that works with easy generated code, except when you want to impose the 
use of Angular to the OpenEhr developers, which will become 
contradictory with the word "Open". I think it is best to offer the 
developer as much freedom as necessary, it makes the effort to create 
this also longer usable and ask for less maintenance.


Therefor I wouldn't go the way of an existing framework anyway, it is 
much easier to generate javascript (as simple as possible) and GUI 
identifiers together with the necessary REST-calls
The generated javascript can be quite simple, a  GUI-control, an 
identifier to read the content, and a REST-call which uses the content 
to do its thing.
When developers want, they an copy and paste the generated javascript 
into their web-framework in order to maintain the own graphical layout 
and application functionality around the generated code.

Integration will become much easier.

You could optionally make it more complex (as a second step goal) and 
still work for the simple copy/past situation. This complexity could be 
in validating datasets in the browser by Javascript/Typescript, so there 
will be only network activity when the dataset is validated and OK. That 
would really do the user-experience good, especially on mobile devices.


But this second step could be a later target, first having the simple 
javascripts generated and the REST calls generated would be a good 
target to start with.


Best regards
Bert





yes - this is the sort of thing I have in mind. The tool would 
function as follows:


  * represent UI forms and ?other UI behaviours (some screen workflow)
as archetypes+templates of classes that generically represent such
things
  * use one or a set of templates to represent an application
  * generate the OPTs of these templates, as ADL2 or JSON, YAML,
whatever is convenient
  * perform OPT => GUI transform, injecting some UI styling profile
info, to get directly consumable artefacts for the UI framework.

experts on the UI side will be able to help refine the details of this.

THe 'smart split' of data / UI semantics will be the key to making 
this workable.


- thomas




Also looking at the things done in the format used/shared by Marand 
and DIPS is an interesting input for gathering requirements.


//Erik Sundvall



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

Re: HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

2018-02-17 Thread Bert Verhees


On 17-02-18 16:33, Pablo Pazos wrote:
I think that is the expected behavior, also what is returned depends 
on the operators in the SNOMED expression, like << will return all 
descendants. The expression can be tuned to return just what you want, 
and the process of the result should work considering those results.


Of course, if not so, it can easily flow over the capability of machines 
and networks, tuning is one of the most important subjects when querying 
very large repositories.


Bert


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

Re: Optmizing AQL

2018-02-17 Thread Bert Verhees


On 17-02-18 16:22, Pablo Pazos wrote:

Just thinking out loud! But I'm working towards this with Diego :)


Ah, I didn't know that. I must read the mailing-lists more often.

Good luck with that. I am very interested to hear about proceedings and 
plans


Bert


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

Re: HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

2018-02-17 Thread Bert Verhees


On 17-02-18 16:39, Pablo Pazos wrote:

That is why SNOMED alone can't be used for querying.


I agree with that, else, you would not need OpenEhr at all ;-)


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

Re: HRe: openEHR REST APIs - Release 0.9.0 / invitation for ,

2018-02-17 Thread Bert Verhees


On 17-02-18 11:21, GF wrote:
That context/epistemology is defined by meta-data in COMPOSITION that 
as committed to databases and documents.


That is why OpenEhr and SNOMED can be a strong combination.


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

Re: Optmizing AQL

2018-02-17 Thread Bert Verhees


On 17-02-18 15:47, Diego Boscá wrote:

https://bioportal.bioontology.org/

It has tons of knowledge exposed as queriable web services. All 
services have an RDF output, so is perfect to demonstrate linked data


Thanks, very interesting


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

Re: Optmizing AQL

2018-02-17 Thread Bert Verhees


On 17-02-18 13:11, Diego Boscá wrote:
Maybe it is possible to generalize it in a way that it could be 
external calls that return a value or list of values. Maybe this is 
enough for SNOMED, CDSS, but also for queries to linked data such as 
drug-drug interaction and other services availabe in bioportal, etc.


Hi Diego, I don't know what bioportal is, and how you want to find 
drug-drug interactions. In the Netherlands we have a large and well 
maintained data-vendor for this purpose, called Z-index. But I found 
that SNOMED itself also has drug-drug interactions, and it can, maybe, 
also become a national extension to SNOMED, because drugs often differ 
from country to country.


Maybe this can be decided later, and that first the focus will be on the 
SNOMED part.


I was thinking in your suggested way too (I think), that a special 
value-list-layer is added inside the AQL query-engine, which can do some 
comparison at the moment the AQL engine creates a result-set (internal)


What is important to decide is that the AQL is using a SNOMED resultset, 
and not the other way, so the AQL has the deep magic layer.
So the magic will happen at a deep internal level the AQL part using the 
SNOMED part cannot be at AQL-API-level, because that would be the same 
as doing the queries separately, and that would be very costly. 
Although, for a start, this is possible.


For SNOMED, I found there are API's defined or being defined, so that 
would be the stable part.


What is very important, but maybe that is already taken care of, we need 
a formal way to include a SNOMED expression into an AQL query.


If we are able to separate a SNOMED part from the AQL part, and define 
how it interacts with the AQL part, then we can parse that SNOMED part 
in a microservice and hand over the result to the database-specific AQL 
engine maintainers/developers.


Bert



2018-02-17 9:23 GMT+01:00 A Verhees >:


The discussion Pablo has makes me think it could be good to have
in an AQL-engine an entry to have external query languages
executed like SNOMED expressions which can treat result data as
hierarchies of data and so add an extra functionality layer

Bert

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


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






--

VeraTech for Health SL 

Twitter LinkedIn 
Maps 



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

VeraTech for Health SL
+34 961071863  / +34 627015023 


www.veratech.es 

Su dirección de correo electrónico junto a sus datos personales forman 
parte de un fichero titularidad de VeraTech for Health SL (CIF 
B98309511) cuya finalidad es la de mantener el contacto con usted. 
Conforme a La Ley Orgánica 15/1999, usted puede ejercitar sus derechos 
de acceso, rectificación, cancelación y, en su caso oposición, 
enviando una solicitud por escrito a verat...@veratech.es 
.




___
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: Archetype pattern

2018-02-16 Thread Bert Verhees

Dear Athanasios,

A pattern must be imposed so strongly to an archetype, that even a 
clinician cannot escape them. That is the idea. Conforming to SNOMED may 
not be the best idea, but it is not a bad idea. It is a restriction 
which impose connections and hierarchy and still allows a user needed 
level of granularity

Bert

On 16-02-18 10:24, Anastasiou A. wrote:

Hello Bert and all

Thank you for your reply, please see below:

> every path unpredictable if there is no pattern used, so you can 
find many examples of your own

Alright, sounds like a pattern by itself :) I cannot say this brings 
an obvious example to mind.

This unpredictability though might be due to another reason (please 
see below).

> So clinicians and technicians create different archetypes, how about 
the medical informatics specialists, how about other cultures, how 
about people in between?

> I am sure that every person creates different archetypes, especially 
when you look at the small details which are so important when querying.

> ...

> A similar kind of semantic pattern is also in SNOMED but then 
tailored to the clinical world.

I think that this goes right to "the heart of the problem" and the 
keyword here is "Culture", or maybe even isolated cultures.

Even people from the same discipline cannot get to communicate sometimes.

SNOMED and openEHR were not developed together. When you develop a 
model you have an objective in mind. The model is built to be able to 
answer a specific question (or range of questions). SNOMED is built 
with a different set of specifications and its granularity does not 
have to conform to anything other than its specifications.

So, you either try to make best use of both "tools" in isolation or, 
you stand back and think about integrating them (but again with a 
specific objective in mind).

In either case, I think that anyone who wants to start working in this 
domain needs to have a basic understanding of a few things (e.g. What 
is this thing called a "Data Model", what does the process look like, 
what is object orientation, what is abstraction, what constitutes an 
entity, what constitutes an attribute, what constitutes a 
relationship, what types of relationships are there and what do they 
mean in context and many other "basics".) as well as other models they 
are going to have to work with.

Otherwise, you get those "unpredictable results".

My experience has been that before you get people "excited" and 
engaged with this type of work, they first have to understand what it 
is and what is the value it brings to THEIR work.

Most of the times, if you mention "Data Modelling" to someone from a 
health related environment (whether research or clinical), they 
immediately think numerical models.

Finite modelling, is not even on the map. Someone is more likely to 
have (simply) heard of the logistic equation as a model of growth 
rather than generalisation as a way of specialising an entity. And we 
are talking "simple marketing" here. Just to have heard the term, they 
don't have to know exactly what it is.

So, for this environment, Patterns are Science Fiction. If someone 
doesn't get abstraction, they will not "arrive" at patterns.

This creates a mismatch between the technical and clinical communities 
which can probably be lowered by educating each other. I am probably 
equally frustrated about all the different types of Blood Pressure as 
a clinician is with all the different types of data structures but 
both are necessary, we are not trying to waste each other's time. I 
too need to know what the domain looks like to understand the 
objectives that the models are trying to satisfy. I am not saying that 
the clinicians are "lacking", I am "lacking" too :D

All the best

Athanasios Anastasiou

From: Bert Verhees [mailto:bert.verh...@rosa.nl]

Sent: 15 February 2018 16:29

To: Anastasiou A.

Subject: Re: Archetype pattern

On 15-02-18 16:52, Anastasiou A. wrote:

Hello Bert

I think that this is an interesting topic from a number of aspects.

Can I please ask what do you mean by "clinicians create archetypes 
with unpredictable paths"? Can you provide one or two examples?

Hi Athanasios, in fact is every path unpredictable if there is no 
pattern used, so you can find many examples of your own.

I think the EHR-classes in the RM is too coarse grained to guarantee 
predictable pattern. We can also see that in the WIKI from Heather Leslie.

I quote: "It has been observed on many occasions that even with 
identical clinical requirements, a clinical modeller and a technical 
modeller will build quite different archetypes. Which archetype best 
represents the data recording requirements? In most cases it will be 
the clinical modeller's attempt which is more useful, although 
technical input will be required to en

Re: openEHR REST APIs - Release 0.9.0 / invitation for comments

2018-02-16 Thread Bert Verhees

I think, it would be good if the community who did this fantastic job, 
should also divide a kernel in micro-services and having interfaces 
between them, and let there be one entry-service to have the 
micro-services expose themselve to the outside world over REST, for now.


There is knowledge about how to structure micro-services, how which 
pattern to sue, between them and inside the service.


The kernel for OpenEhr is too large for not dividing it. Think about:
- OpenEhr-Terminology,
- Archetype parsing,
- Archetype serializing,
- Storage,
- Validating of data,
- validating of users/authorizations (or connecting to an external 
user-service),

- measurement (ucum),
- SNOMED,
- Patient repository (connecting to external)
- Messaging to other EHR eco-systems
- Internal Message queue

It would be a great help if these microservices were defined, so 
everyone could build and borrow them, when they are defined on community 
level, they will be interchangeable.


This is a good starting point for learning about that subject, but an 
experienced architect would be welcome.

https://www.packtpub.com/application-development/microservice-patterns-and-best-practices

Bert




On 16-02-18 12:38, Thomas Beale wrote:



I've been developing an abstract version of the platform definition in 
the background, mostly reverse-engineered from the REST API, in order 
to capture the pure call semantics (i.e. without HTTP protocol 
effects, JSON or XML serialisation etc), and in that I proposed two 
interfaces, one for ADL14 and one for ADL2, which seems a clearer 
approach to me - see here 
. 
This might be helpful in determining the separation we want.


- thomas


On 15/02/2018 13:09, Pieter Bos wrote:

I noticed the recent version of the REST api  only works with templates, and 
not archetypes.

As our EHR is ADL 2 only, this has some interesting consequences.

Of course, you can upload just the operational templates and probably create a 
fully functional EHR, but if you work with ADL 2, you would always need an 
external tool to create the OPT2 from the ADL repository that you want to use, 
instead of an EHR that generates the OPT2s from the source archetypes itself. 
Of course, you could just use the ADL workbench or the Archie adlchecker 
command-line utility to do it for you, but I’m not sure if it’s a nice thing to 
do.

Also if you only use OPT2, you might want to do queries such as ‘retrieve all 
information that is stored in an EHR that has been derived from archetype with 
id X, including archetypes specializing from X’ (not just operational template 
X). An example: retrieve all reports, or all care plans, regardless of the used 
template. To do that, you probably need a specialization section in the OPT2, 
which according to the specs should have been removed, and you also need to 
create operational templates for archetypes that you never use to directly 
create compositions from. Or the tool querying the EHR must be fully aware of 
the full archetype specialization tree and use that to create a query with all 
specializing archetypes included in the query.

So, is it intended that the REST API only works with operational templates, and 
never archetypes?

Regards,





___
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: Archetype pattern

2018-02-16 Thread Bert Verhees


On 16-02-18 12:41, Thomas Beale wrote:



in openEHR terms...

On 16/02/2018 05:38, GF wrote:

Hi all,

In my opinion there are several types of ‘patterns’:

- Specific Local Templates/patterns used in a defined community for 
specific purposes


specialisations of any archetype for local usage.
I don think you should ever create an archetype in the idea that it is a 
local archetype. I think you can never guarantee that. Archetypes are a 
model of thinking, a semantic model, instead of a technical model, like 
Codd-normalization.
So in an other situation there will also be the need to express the same 
way of thinking in an archetype, but they will probably structure it 
different.

That is something were we should find a way to avoid that.



- Specific Clinical Models/patterns for things like: the 
documentation of lab-test forms/panels, collections of meta-data for 
documentation of specific observations/test for abdominal complaints, 
etc.


COMPOSITION archetypes, probably some SECTION archetypes
Sections are, I think, a problem, they are part of the path, so they 
change query-paths and can make data invisible, because maybe no one 
thought of a section when searching in a database.
I don't know if AQL has a wild-card to pass sections without paying 
attention to them. I think that is necessary.


Bert

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

Re: Archetype pattern

2018-02-16 Thread Bert Verhees

ntologies are useful but don't necessarily 
cater for the entire reality that is clinical practice. Engineer review and 
input would be much appreciated if it were available.

Why don't you agitate to get more engineers participating in the reviews? I 
would gladly invite anyone who is willing to engage. Get them to adopt an 
archetype today and join in the collective effort - the resulting archetypes 
can only be better for everyone.

Regards Heather

-Original Message-
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On 
Behalf Of Bert Verhees
Sent: Friday, 16 February 2018 2:41 AM
To: For openEHR technical discussions <openehr-technical@lists.openehr.org>
Subject: Archetype pattern

An interesting wiki from Heather Leslie

https://openehr.atlassian.net/wiki/spaces/healthmod/pages/90507705/Archetype+Design+Patterns

She concludes that pattern are necessary, I agree with that, and she also 
concludes that clinicians are better modelers then technicians.

Well, that depends, of course it is very important to have domain-knowledge 
when modeling data, and clinicians have the best domain-knowledge. So from that 
point of view, she is right.

But what we have seen until now is that clinicians create archetypes with 
unpredictable paths. And that is bad, because it makes it very difficult to 
find data and it makes it easy to miss important data, because some data were 
on a path where one did not expect them.

OpenEhr works fine to find data which are on a known or predictable path, but 
what if data are on an unknown path?

Let me explain by comparing this to a classical relational health-application. 
There are similarities.

I have seen classical relational systems which experienced a wild-grow in 
number of tables, I have seen once in a prestigious university-hospital where 
they had a grown of 7000 tables in 20 years, more then one per day!! No one 
understood the meaning of all the tables and data, no one dared to use data he 
did not understand, many data were and still are redundant. Every new 
development in the ICT starts with designing new tables.

How can in such a situation a clinician research a persons medical record, even 
with the help of the current technical staff, this is often impossible. So, 
important information can get lost. Adding to this are software-updates which 
often cause a clean-up, and that clean-up is also done by people who do not 
always know what they clean up. People live long, and a medical problem they 
had 30 years ago can be important to find to solve a current problem. So old 
data, and understand them, and be able to find them, can be important.

This can also happen with archetypes. Every new development in a application 
can start with a new archetype, and at a moment there can be thousands. It is 
impossible for a clinician to search all possible paths for medical 
information, even with the help of the current technical staff this can be 
impossible.

The old data-hell situation will not be solved by OpenEhr if there is not 
something behind it. And that something, that is: PATTERN

It is not only a clinical thing to understand how pattern in paths are best 
modeled, it is in fact also a technical thing. Clinical knowledge is not 
stable, the thinking about clinical facts change all the time, what now is 
important is tomorrow maybe not. So the pattern need a technical, mathematical 
base, that, something like Codd-normalization, but of course then applicable to 
archetypes.

The Wiki from Heather Leslie is a good starting point for the design of pattern 
and stop the proliferation of paths.

I described an approach to solve this problem in a blog, one and a half year 
ago.

http://www.bertverhees.nl/openehr/medical-data-context/

I had some discussion about that, but many had problems against the use of 
SNOMED in this context. So, maybe read it and forget SNOMED ad find something 
else to structure the medical data.

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




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

Archetype pattern

2018-02-15 Thread Bert Verhees

An interesting wiki from Heather Leslie

https://openehr.atlassian.net/wiki/spaces/healthmod/pages/90507705/Archetype+Design+Patterns

She concludes that pattern are necessary, I agree with that, and she
also concludes that clinicians are better modelers then technicians.

Well, that depends, of course it is very important to have
domain-knowledge when modeling data, and clinicians have the best
domain-knowledge. So from that point of view, she is right.

But what we have seen until now is that clinicians create archetypes
with unpredictable paths. And that is bad, because it makes it very
difficult to find data and it makes it easy to miss important data,
because some data were on a path where one did not expect them.

OpenEhr works fine to find data which are on a known or predictable
path, but what if data are on an unknown path?

Let me explain by comparing this to a classical relational
health-application. There are similarities.

I have seen classical relational systems which experienced a wild-grow
in number of tables, I have seen once in a prestigious
university-hospital where they had a grown of 7000 tables in 20 years,
more then one per day!! No one understood the meaning of all the tables
and data, no one dared to use data he did not understand, many data were
and still are redundant. Every new development in the ICT starts with
designing new tables.

How can in such a situation a clinician research a persons medical
record, even with the help of the current technical staff, this is often
impossible. So, important information can get lost. Adding to this are
software-updates which often cause a clean-up, and that clean-up is also
done by people who do not always know what they clean up. People live
long, and a medical problem they had 30 years ago can be important to
find to solve a current problem. So old data, and understand them, and
be able to find them, can be important.

This can also happen with archetypes. Every new development in a
application can start with a new archetype, and at a moment there can be
thousands. It is impossible for a clinician to search all possible paths
for medical information, even with the help of the current technical
staff this can be impossible.

The old data-hell situation will not be solved by OpenEhr if there is
not something behind it. And that something, that is: PATTERN

It is not only a clinical thing to understand how pattern in paths are
best modeled, it is in fact also a technical thing. Clinical knowledge
is not stable, the thinking about clinical facts change all the time,
what now is important is tomorrow maybe not. So the pattern need a
technical, mathematical base, that, something like Codd-normalization,
but of course then applicable to archetypes.

The Wiki from Heather Leslie is a good starting point for the design of
pattern and stop the proliferation of paths.

I described an approach to solve this problem in a blog, one and a half
year ago.

http://www.bertverhees.nl/openehr/medical-data-context/

I had some discussion about that, but many had problems against the use
of SNOMED in this context. So, maybe read it and forget SNOMED ad find
something else to structure the medical data.

Bert

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

Re: openEHR-technical Digest, Vol 72, Issue 4

2018-02-07 Thread Bert Verhees

My two cents, an opinion on a detail issue

The disadavantage of Vaadin may be that it is server based, most of the 
logic runs on the server, and this makes an application less scalable 
and causes more network traffic. This is because data-validation is done 
on the server and the result send back to the client if there is a problem.
Especially on slow networks this can be  a big problem. And you will be 
amazed how many slow networks there are on the world, not in an 
university, but in villages in the South of France or the North of the 
Netherlands, also South America, Africa, Asia, but also in parts of 
Kansas, Oklahoma, West Virginia, most people on the world, when they 
have Internet, they have it on a slow network.

When you want to make money, you will need those people as client of 
your products.
People have tablets, IoT-devices, they are doing a lot of their own 
healthcare, that is the near future coming.

Better would be better to validate data on the client and only send data 
to the server if it is valid. Only UID's needs to be validated on the 
server, because for validating UID's server-knowledge is needed. But for 
data-against-archetype-validation, most of the validation knowledge can 
run on the client, and GUI can respond instantly on errors. That is what 
we want, we don't want a delay of three seconds to tell us that the 
heart-rate figure is not realistic.

Of course, this causes some problems, but it is not impossible. For this 
purpose it is needed that validation-software needs to run on the 
client. One can think of Java-validation-software, but that causes all 
kind of permissions that need to be given, and it creates a dependency 
to the JVM version on the client. So that is also not desirable.

Clients all run Javascript, and better, the superset Typescript. So it 
would be good if archetypes/templates could be parsed client side. The 
server only would need to send the smart minimalistic form-description 
and the template, and wait for a valid dataset result.

The client would create a form from the description, parse the 
template/archetype/validate the data and only send back the result.

Think about it, there is need for an Archie-library based on Typescript. 
A good starting point, check here

https://github.com/antlr/antlr4/blob/master/doc/javascript-target.md

I am very interested who will take up the gauntlet

Best regards
Bert Verhees

On 06-02-18 18:42, Ricardo Gonçalves wrote:
On the "putting together a web frontend and a Java backend" topic, it 
may be interesting to look at Vaadin, which is an open source 
framework to build web applications using Java (you code everything in 
Java, an equivalent GUI is generated and all behavior that comes from 
user interaction is actually triggered on the backend through a 
protocol like RPC; pretty much like the old GWT but smarter and with 
less boilerplate code). They also have a dev preview on something 
called Flow, which is supposed to give a Java backend direct access to 
the DOM, somewhat similar to real-time server-side rendering but with 
an optimised communication protcol instead (no need to care about 
APIs, REST, whatever). Anyway, since we're already on a Java 
ecosystem, those may be easier than modeling APIs and adopting 
JavaScript frameworks that may or may not be alive tomorrow.

Att.,
Ricardo Gonçalves.

On 06/02/2018 15:00:31, openehr-technical-requ...@lists.openehr.org 
<openehr-technical-requ...@lists.openehr.org> wrote:

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: Announcing Archie version 0.4 (Thomas Beale)

--

Message: 1
Date: Mon, 5 Feb 2018 19:04:35 -0300
From: Thomas Beale
To: openehr-technical@lists.openehr.org
Subject: Re: Announcing Archie version 0.4
Message-ID: <5e6cf155-c2ea-cf69-a8d0-402ed025c...@openehr.org>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

yes, JS = javascript, TypeScript etc. No, nothing to do with Java of
course. Just that JS/TS are the languages that seem to be popular for
web app development these days, and Java for the back-end. The
connection between front and back-end that people seem to prefer these
days is REST APIs, which both Java and JS can do easily enough.

- thomas

On 03/02/2018 07:56, Peter Gummer wrote:
> On 1 Feb 2018, at 05:13, Thomas Beale
> > wrote:
>>
>> ... But the main

1 2 3 4 5 6 7 8 9 >

1 - 100 of 802 matches

Mail list logo