Re: UCUM code in body temperature archetype

[Gerard Freriks (privé)]

An alternative for dealing with semantic in archetypes is dealing with 
semantics in coding systems like SNOMED.

The consequence is that SNOMED must be a complete Medicinal Product Formulary.
I have doubts whether this is a good idea.

Many countries have different specific formularies.
I like to reserve SNOMED-CT to use as any dictionary with universal lemma’s, 
concepts.
Each country will have its own maintained Formulary.
A formulary that changes because of the marketing whims of pharmaceutical 
companies.


Gerard Freriks
+31 620347088
gf...@luna.nl <mailto:gf...@luna.nl>
> On 19 mei 2016, at 10:09, Ian McNicoll <i...@freshehr.com> wrote:
> 
> Hi Thomas,
> 
> In the UK (and ? Aus/NZ), we would not use arbitrary units in UCUM for dose 
> units because the latter are expressed as SNOMED terms, and are used in 
> conjunction with the SNOMED-based dm+d (or AMT) drug dictionary to compute 
> actual doses/amounts where possible.
> 
> e.g.
> 
> 318421004 | Atenolol 100mg tablets |
> 
> via dm+d allows us to infer that 1 tab (in this case) = 100mg
> 
> http://dmd.medicines.org.uk/DesktopDefault.aspx?VMP=318421004=nofloat 
> <http://dmd.medicines.org.uk/DesktopDefault.aspx?VMP=318421004=nofloat>
> 
> and allows us to do maximum daily dose calculation, at least against a 
> defined subset of such 'dose units'.
> 
> in other cases the dose unit strength will be defined as part of the 
> medication order - we have a 'Strength' element in the medication order 
> archetype for just such a purpose.
> 
> I don't think we need to be able to define the unit strength as part of the 
> quantity datatype.
> 
> 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 19 May 2016 at 08:24, Thomas Beale <thomas.be...@openehr.org 
> <mailto:thomas.be...@openehr.org>> wrote:
> Hi Gerard,
> they actually could be, but whenever this discussion comes up, no-one 
> proposes it. I'm not sure if I would either, because these arbitrary units 
> are still not computable in general, but 'dose units' can be made computable 
> but only with some extra data fields, i.e. you need both the quantity of dose 
> in 1 tablet/capsule etc, and also number of tablet/capsule etc. So the 
> structural model is different anyway.
> 
> I think the other problem with using UCUM arbitrary units is that people / 
> orgs want to control the names of medicinal delivery products ('tablet' etc) 
> in a terminology, which is reasonable, but doesn't fit so well with UCUM.
> 
> - thomas
> 
> On 19/05/2016 08:11, "Gerard Freriks (privé)" wrote:
>> Thomas,
>> 
>> All are Units of a different kind.
>> 
>> SI defines: Units of Measure, and Units of Quantity in the scientific domain.
>> 
>> There are also Units of Time: minute, hour, etc.
>> 
>> When I think of tablets, capsule, etc. we will call these Units of Medicinal 
>> Product Dose.
>> Isn’t in UCUM this an example of Arbitrary Units?
>>  <>3.2 
>> ARBITRARY UNITS
>>  <>§24 arbitrary units   ■1 Arbitrary or procedure defined units are 
>> units whose meaning entirely depends on the measurement procedure (assay). 
>> These units have no general meaning in relation with any other unit in the 
>> SI. Therefore those arbitrary semantic entities are called arbitrary units, 
>> as opposed to proper units. The set of arbitrary units is denoted A, where 
>> A∩ U = {}.   ■2 An arbitrary unit has no further definition in the semantic 
>> framework of The Unified Code for Units of Measure  ■3 Arbitrary units are 
>> not “of any specific dimension” and are not “commensurable with” any other 
>> unit.
>> 
>> Until version 1.6 The Unified Code for Units of Measure has dealt with 
>> arbitrary units as dimensionless, but as an effect the semantics of The 
>> Unified Code for Units of Measure made all arbitrary units commensurable. 
>> Since version 1.7 of The Unified Code for Units of Measure it is no longer 
>> possible to convert or compare arbitrary units with any other arbitrary unit.
>> 
>>  <>§25 operations on arbitrary units   ■1 Any term involving arbitrary 
>> units, is itself an arbitrary unit and is not comparable with any other 
>> arbitrary unit or term.
>> 
>>  <>§26 definition of arbitrary units   

Re: UCUM code in body temperature archetype

[Gerard Freriks (privé)]

Two reactions:

1- There is a difference between the world of semantic interpretability in 
system interfaces and the real word of users looking at screens, and typing on 
keyboards
In one world we can/must use as much as possible SI units via UCUM and strife 
for as detailed as possible reducing misinterpretation.
In the real world users want to have data presented in many shapes and forms.
Accommodating the end-users is the task of the industry.
It is the task of health informaticians to reduce misinterpretations.

At the Template/Interface level we need facilities to annotate as much as 
possible that what is expressed/modelled.
And why not have in the annotations, the printable, the human readable, the 
personal choice, the local choice.

2- When it comes to the Arbitrary UCUM Units.
The question is how much semantic we carry in data types.
And how much semantics we carry in archetypes.
I opt for the latter.
Data types should be as primitive as possible.

I use the UCUM Arbitrary ‘Unit’ and use the structure in the Archetype to 
provide the semantics that describe the Unit.


Gerard Freriks
+31 620347088
gf...@luna.nl 
> On 19 mei 2016, at 09:24, Thomas Beale  wrote:
> 
> Hi Gerard,
> 
> they actually could be, but whenever this discussion comes up, no-one 
> proposes it. I'm not sure if I would either, because these arbitrary units 
> are still not computable in general, but 'dose units' can be made computable 
> but only with some extra data fields, i.e. you need both the quantity of dose 
> in 1 tablet/capsule etc, and also number of tablet/capsule etc. So the 
> structural model is different anyway.
> 
> I think the other problem with using UCUM arbitrary units is that people / 
> orgs want to control the names of medicinal delivery products ('tablet' etc) 
> in a terminology, which is reasonable, but doesn't fit so well with UCUM.
> 
> - thomas
> 
> 

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

Re: UCUM code in body temperature archetype

[Gerard Freriks (privé)]

Thomas,

All are Units of a different kind.

SI defines: Units of Measure, and Units of Quantity in the scientific domain.

There are also Units of Time: minute, hour, etc.

When I think of tablets, capsule, etc. we will call these Units of Medicinal 
Product Dose.
Isn’t in UCUM this an example of Arbitrary Units?
 <>3.2 
ARBITRARY UNITS
 <>§24 arbitrary units   ■1 Arbitrary or procedure defined units are units 
whose meaning entirely depends on the measurement procedure (assay). These 
units have no general meaning in relation with any other unit in the SI. 
Therefore those arbitrary semantic entities are called arbitrary units, as 
opposed to proper units. The set of arbitrary units is denoted A, where A∩ U = 
{}.   ■2 An arbitrary unit has no further definition in the semantic framework 
of The Unified Code for Units of Measure  ■3 Arbitrary units are not “of any 
specific dimension” and are not “commensurable with” any other unit.

Until version 1.6 The Unified Code for Units of Measure has dealt with 
arbitrary units as dimensionless, but as an effect the semantics of The Unified 
Code for Units of Measure made all arbitrary units commensurable. Since version 
1.7 of The Unified Code for Units of Measure it is no longer possible to 
convert or compare arbitrary units with any other arbitrary unit.

 <>§25 operations on arbitrary units   ■1 Any term involving arbitrary 
units, is itself an arbitrary unit and is not comparable with any other 
arbitrary unit or term.

 <>§26 definition of arbitrary units   ■1 Arbitrary units are marked in the 
definition tables for unit atoms by a bullet (‘•’) in the column titled “value” 
and a bullet in the column titled “definition”.



Gerard Freriks
+31 620347088
gf...@luna.nl 
> On 18 mei 2016, at 13:41, Thomas Beale  wrote:
> 
> 
> On 18/05/2016 12:21, Grahame Grieve wrote:
>> The main problem is that ucum units are not human readable units,
> 
> right - my idea 13 years ago was to use the UCUM string as a key into 
> something that generated a human-readable form. For reasons that became 
> clearer since, I think we all agree that we need to embed not just the formal 
> form, but the human-readable form as well. So that's a fairly anodyne design 
> problem for the Quantity type in everyone's type system. I think we can solve 
> that in a reasonable way in openEHR.
> 
>> and trying to force them to be will generate substantial pushback from end 
>> users. In USA, this is an open problem for CDA adoption. In Australia, I 
>> solved it by declaring that we would never retire valid ucum units in CDA.
>> 
>> A secondary problem is discrete units like tablet, capsule etc which have no 
>> computable form in ucum
> 
> I suspect this is the main problem for some people at least these days. 
> Scientifically speaking, anything like 'tablet', 'capsule', 'drop' etc isn't 
> a 'unit' in the science/physics sense; but in English (and most other 
> languages I suspect) we use the same word in a non-science sense to mean 
> 'discrete amount of anything', e.g. unit shares, 5mg tablet is the unit of 
> dosing, and so on. This makes people think the problem can be solved within 
> the model / language of scientific units. It can't in any clean way.
> 
> So dose 'units' need to be understood as something different from scientific 
> units, and modelled in a different way. They are units of discretisation or 
> quantisation of material, not units of physical properties.
> 
> - thomas
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

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

Re: SNOMED

[Gerard Freriks (privé)]

Thomas,

I fully agree,
as you know, already.

Gerard

Gerard Freriks
+31 620347088
gf...@luna.nl 
> On 29 apr. 2016, at 16:42, Thomas Beale  wrote:
> 
> Hi Bert
> Erik and Ian partly answered this, but it is always worth remembering that 
> SNOMED CT, if based on proper ontological principles, contains assertions 
> that represent entities in the real world. This means taxonomy (IS-A) and 
> properties, qualities, possible relationships and so on (see BFO2  
> for
>  a modern top-level ontology providing these ideas). These are properties, 
> qualities and relationships of real things in the real world, i.e. actual 
> hearts, cardiac arrests, disease types and so on.
> 
> The openEHR RM and derivative archetypes are built to represent information 
> 'about' these real things. The relationship is often written as 'is-about'. 
> There are important differences to be aware of:
> what information is written 'about' many things can sometimes resemble a 
> description of the thing itself, e.g. parts of a colonoscopy report tend to 
> follow anatomical structure of colon and things found in it; 
> sometimes it relates to a surrogate phenomenon, e.g. an archetype for heart 
> rate that actually records pulse; a great deal of clinical observation is of 
> surrogates e.g. state of skin, palpation, heart sounds, asking about pain, 
> blood glucose etc, but they are actually about something else; 
> what gets recorded can be what is cheap and painless to record; consider that 
> we don't do an echocardiogram every time you want simple BP or heart rate.
> what gets recorded about X can be culturally determined; different in other 
> ways from 'how X really is' in nature.
> most important: most clinical data recordings don't replicate 'textbook' 
> relationships found in an ontology, e.g. the fact that there are 5 heart 
> Korotkoff sounds at different phases of the cardiac cycle will never be 
> written down by a physician, neither will the fact that systolic BP is-a 
> pressure of blood in a vessel is-a pressure of fluid in a vessel etc. So if 
> we were to generate an information structure from part of an ontology 
> representing the heart / CV system, it would generate numerous useless data 
> points and relationships on the information side.
> How well or how much SNOMED CT follows underlying ontologies like BFO2 or 
> Biotoplite or whatever is another question. I am not up to date on the 
> progress, but I am fairly sure that most of SNOMED has not been validated 
> against these kinds of ontologies. The waters are muddied further by the 
> attempts to represent informational, timing and context-related entities in 
> SNOMED CT.
> 
> Thus, my view is that: in principle, generating information structures 
> straight from an ontology (even a perfectly built one) will simply never 
> work, for the reasons in the list above; in practice, what you would get from 
> SNOMED CT, given its imperfect adherence to ontology would be even harder to 
> understand or use.
> 
> - thomas
> 
> On 29/04/2016 07:50, Bert Verhees wrote:
>> Hi, 
>> 
>> I got an idea when reading the nice story from Heather on LinkedIn. In fact 
>> it is hers idea, but in a opposing way. 
>> https://www.linkedin.com/pulse/journey-interoperability-part-i-heather-leslie
>>  
>> 
>>  
>> https://www.linkedin.com/pulse/journey-interoperability-part-ii-heather-leslie
>>  
>> 
>>  
>> 
>> I wonder in how far it is feasible and useful to create archetypes from 
>> SNOMED concepts, it would be possible to generate them, with attributes and 
>> so on. 
>> In a few hours time, one would have a complete forest with archetypes, 
>> including ontology in more languages. 
>> Maybe some smart handling, filtering, combining can create a better 
>> collection, also looking at the paths, so that there are similar paths for 
>> similar situations, to keep the number of different datapoints low, which 
>> can help creating a faster key-value storage. 
>> 
>> I don't know how it is about copyright, with members, and licensing, that 
>> should be looked at. 
>> 
>> The argument that SNOMED is fragmented should not count, I think (however 
>> without having an expertise on this), because, when working with handwritten 
>> archetypes will always be incomplete and fragmented. 
>> 
>> Bert 
>> 
>> ___ 
>> openEHR-technical mailing list 
>> openEHR-technical@lists.openehr.org 
>>  
>> 

Re: SNOMED

[Gerard Freriks (privé)]

Ian,

I need to correct you.

1- CIMI and SNOMED.
The nodes are NOT labeled using SNOMED, but LOINC is used.
SNOMED is reserved for the data fields.

2- SNOMED is a Reference Terminology and should in the ideal world be 
orthogonal to structures as used in HL7v2, v3, and 13606.
The natural role of SNOMED is to define ‘atomic’ concepts like any dictionary. 
These concepts are universal.

In the ideal world the structures equate the syntax of a sentence and the 
Reference Terminology provides the ‘atomic’ concepts, the words.

The dictionary defines for instance the concept: 'story’.
And defines the concepts; ’tell’, ' by’, ‘as’, ‘patient’ and ‘mother’.
The dictionary never describes as one single concept: ‘Story as told by mother’.
This complex, pre-co-ordinated, concept is no longer universal, but specific.
In language we use the syntax and the ‘atomic’ words to create statements.
In the world of archetypes we use structure and ‘atomic’ codes to create 
Archetypes.

3- Helas SNOMED started to incorporate things from the world of structures in 
their coding system.
They were no longer orthogonal.

For example:
The dictionary defines for instance the concept: 'story’.
And defines the concepts; ’tell’, ' by’, ‘as’, ‘patient’ and ‘mother’.
The dictionary never describes as one single concept: ‘Story as told by mother’.
This complex, pre-co-ordinated, concept is no longer universal, but it is 
specific, it is particular.
In language we use the syntax and the ‘atomic’ words to create statements.
In the world of archetypes we use structure and ‘atomic’ codes to create 
Archetypes.

4- CIMI decided to use the ‘atomic’ codes, as much as possible in their 
structures in order to express results in data fields and use LOINC to label 
nodes.
This is the CIMI preferred way.
And yes, as a service, iso-sematic expressions are provided, but these are NOT 
the CIMI preferred way.

Gerard

Gerard Freriks
+31 620347088
gf...@luna.nl 
> On 29 apr. 2016, at 16:01, Ian McNicoll  wrote:
> 
> Hi Bert,
> 
> This is going to sound controversial but ...
> 
> I am a big fan of SNOMED-CT and at some pint in the far distant future, what 
> you are proposing (or something like it) will happen. However, I have seen 
> endless similar proposals/projects in the UK and beyond, entranced by the 
> potential of post-coordination, repeatedly falling over, wasting huge amounts 
> of resource and energy and achieving nothing. That includes CIMI, which has, 
> IMO, been largely stalled by setting itself the goal of labelling all CIMI 
> nodes as SNOMED terms, and for archetypes being 'iso-semantic' with 
> post-coordinated SNOMED expressions.
> 
> Whilst this is a laudable goal, it is hugely complex and it is, I think 
> significant that where progress has been made (openEHR and FHIR) both have 
> largely taken a prgamatic and limited approach to use of SNOMED-CT.
> 
> SNOMED is a primarily an ontology of biomedical fact, not of clinical 
> practice/documentation. Used
> 
> @Erik - we have only just been asked to resume discussion with IHTSDO. The 
> view of the MB is that it is not our place to police the use of SNOMED-CT by 
> end-user systems. All SNOMED-CT bindings in openEHR artefacts are optional 
> mappings. We are happy to add a boilerplate license to each archetype (as for 
> any third-party IP) that implementers must ensure that any use of SNOMED-CT 
> is allowed. There is no intention to otherwise adapt or strip-out content for 
> unlicensed consumers, as I think you were suggesting. If IHTSDO feel the need 
> to enforce more onerous terms than a simple boilerplate "Please respect IP" 
> statement, I think we might find that very problematic.
> 
> Regards,
> 
> Ian
> 
> 
> 
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com 
> twitter: @ianmcnicoll
> 
> 
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org 
> 
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
> 
> On 29 April 2016 at 15:45, Bert Verhees  > wrote:
> Thanks Erik, for your reply. I did some more thinking in the meantime.
> 
> In SNOMED you have disorders, and they have attributes, and we all know there 
> are thousands of them. Writing so many archetypes is impossible, and probably 
> not necessary, but when you take in account to limit the number of used 
> paths, (this helps also limiting the length key-index for a key value store), 
> and you really think smart how to do it, so it can be generated.
> 
> Because SNOMED is in fact a description of many clinical meanings with 
> post-coordinate expressions and allowable attributes, just like archetypes 
> are a way to describe the same, it seems quite a potential, especially 
> because it can be used to generate archetypes, I 

Re: Advantage of ISO

[Gerard Freriks (privé)]

Dear Ian,

As I wrote you privately I promised to think over my use of words.
 
Referring to my e-mail with the definition, as I used it, plus the quote from 
the openEHR website,
it must have been clear that I was pointing at ownership of the openEHR 
organisation.
 
I’m aware now, that ‘proprietary’ has an other, different, meaning, when 
applied to software or specifications.
My original e-mail conveyed an unintended meaning, is my conclusion.
 Therefore I will no longer use the word ‘proprietary’ but the phrase ‘ openEHR 
as a company owned by UCL’.

With regards,
 
 Gerard

Gerard Freriks
+31 620347088
gf...@luna.nl 
> On 3 sep. 2015, at 02:07, Ian McNicoll  wrote:
> 
> Hi Bert,
> 
> I am certainly conscious of rumours. Some of these are due to general 
> suspicion of open source licensing (and we can, I think, do more to alleviate 
> this)  but I am afraid some of anxiety is also caused by inaccurate and 
> misleading information "openEHR is proprietary",  regularly stated by a small 
> number of individuals. I have had to ask for these to be corrected in a 
> number of documents e.g. The SemanticHealthNet report where it was agreed by 
> the principal authors, including Dipak, to be incorrect.
> 
> Since a significant number of companies and national organisations now make 
> use of openEHR specifications or artefacts, these statements are being 
> regarded as commercially hostile and the Foundation Boards both agree that 
> legal action should now be taken where the authors are not prepared to 
> promptly correct this inaccuracy.
> 
> Leaving that aside. I am not convinced that ISO is a good home for openEHR. 
> The specifications, development and revision process in ISO remain completely 
> closed and quite at odds withopenEHR principles but I would be interested in 
> other's views. 
> 
> I do think that some sort of association with a formal standards body would 
> help alleviate some of the anxieties you mention (though these are imaginary) 
> but I am not sure that ISO would be my first choice as it is currently 
> constructed. I will raise the issue of whether to submit AOM2 with the 
> Management Board.
> 
> I am interested in other people's opinions.
> 
> Ian
> 
> 
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com 
> twitter: @ianmcnicoll
> 
> 
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org 
> 
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
> 
> On 1 September 2015 at 16:48, Bert Verhees  > wrote:
> On 01-09-15 17:16, Bert Verhees wrote:
> I have written a text (reply to Erik) in Stackoverflow, describing why it 
> will be good for OpenEHR if AOM2.0 will become an ISO-standard in the context 
> of ISO13606 renewal.
> 
> http://stackoverflow.com/questions/32010122/are-the-hl7-fhir-hl7-cda-cimi-openehr-and-iso13606-approaches-aiming-to-solve/
>  
> 
>  
> 
> I must add, it is not that I suspect anyone of having secret IP on OpenEHR.
> I have no reason to suspect this.
> 
> But I know people who have such suspicions, and having the AOM-part as an ISO 
> standard, surely will fight these rumors.
> 
> I think it will help OpenEHR-implementations to have more customers.
> 
> 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

Re: Advantage of ISO

[Gerard Freriks (privé)]

I will consider this.

Gerard

Gerard Freriks
+31 620347088
gf...@luna.nl 
> On 7 sep. 2015, at 16:02, Ian McNicoll  wrote:
> 
> Thanks Gerard,
> 
> That is very positive and helpful.  Would you consider adjusting to ‘ openEHR 
> is a not-for-profit company established by UCL’ which I hope captures your 
> reservations about single ownership without giving the impression that this 
> is a 'for-profit 'company?
> 
> Ian

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

Re: Advantage of ISO

[Gerard Freriks (privé)]

Dear Ian,

I wrote I will consider it.

I can accept your proposition.
It is factually the truth.

Gerard

Gerard Freriks
+31 620347088
gf...@luna.nl <mailto:gf...@luna.nl>
> On 7 sep. 2015, at 16:02, Ian McNicoll <i...@freshehr.com> wrote:
> 
> Thanks Gerard,
> 
> That is very positive and helpful.  Would you consider adjusting to ‘ openEHR 
> is a not-for-profit company established by UCL’ which I hope captures your 
> reservations about single ownership without giving the impression that this 
> is a 'for-profit 'company?
> 
> 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 7 September 2015 at 14:38, "Gerard Freriks (privé)" <gf...@luna.nl 
> <mailto:gf...@luna.nl>> wrote:
> Dear Ian,
> 
> As I wrote you privately I promised to think over my use of words.
>  
> Referring to my e-mail with the definition, as I used it, plus the quote from 
> the openEHR website,
> it must have been clear that I was pointing at ownership of the openEHR 
> organisation.
>  
> I’m aware now, that ‘proprietary’ has an other, different, meaning, when 
> applied to software or specifications.
> My original e-mail conveyed an unintended meaning, is my conclusion.
>  Therefore I will no longer use the word ‘proprietary’ but the phrase ‘ 
> openEHR as a company owned by UCL’.
> 
> With regards,
>  
>  Gerard
> 
> Gerard Freriks
> +31 620347088 <tel:%2B31%20620347088>
> gf...@luna.nl <mailto:gf...@luna.nl>
>> On 3 sep. 2015, at 02:07, Ian McNicoll <i...@freshehr.com 
>> <mailto:i...@freshehr.com>> wrote:
>> 
>> Hi Bert,
>> 
>> I am certainly conscious of rumours. Some of these are due to general 
>> suspicion of open source licensing (and we can, I think, do more to 
>> alleviate this)  but I am afraid some of anxiety is also caused by 
>> inaccurate and misleading information "openEHR is proprietary",  regularly 
>> stated by a small number of individuals. I have had to ask for these to be 
>> corrected in a number of documents e.g. The SemanticHealthNet report where 
>> it was agreed by the principal authors, including Dipak, to be incorrect.
>> 
>> Since a significant number of companies and national organisations now make 
>> use of openEHR specifications or artefacts, these statements are being 
>> regarded as commercially hostile and the Foundation Boards both agree that 
>> legal action should now be taken where the authors are not prepared to 
>> promptly correct this inaccuracy.
>> 
>> Leaving that aside. I am not convinced that ISO is a good home for openEHR. 
>> The specifications, development and revision process in ISO remain 
>> completely closed and quite at odds withopenEHR principles but I would be 
>> interested in other's views. 
>> 
>> I do think that some sort of association with a formal standards body would 
>> help alleviate some of the anxieties you mention (though these are 
>> imaginary) but I am not sure that ISO would be my first choice as it is 
>> currently constructed. I will raise the issue of whether to submit AOM2 with 
>> the Management Board.
>> 
>> I am interested in other people's opinions.
>> 
>> Ian
>> 
>> 
>> Dr Ian McNicoll
>> mobile +44 (0)775 209 7859 <tel:%2B44%20%280%29775%20209%207859>
>> office +44 (0)1536 414994 <tel:%2B44%20%280%291536%20414994>
>> skype: ianmcnicoll
>> email: i...@freshehr.com <mailto:i...@freshehr.com>
>> twitter: @ianmcnicoll
>> 
>> 
>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org 
>> <mailto:ian.mcnic...@openehr.org>
>> Director, freshEHR Clinical Informatics Ltd.
>> Director, HANDIHealth CIC
>> Hon. Senior Research Associate, CHIME, UCL
>> 
>> On 1 September 2015 at 16:48, Bert Verhees <bert.verh...@rosa.nl 
>> <mailto:bert.verh...@rosa.nl>> wrote:
>> On 01-09-15 17:16, Bert Verhees wrote:
>> I have written a text (reply to Erik) in Stackoverflow, describing why it 
>> will be good for OpenEHR if AOM2.0 will become an ISO-standard in the 
>> context of ISO13606 renewal.
>> 
>> http://stackoverflow.com/questions/32010122/are-the-hl7-fhir-hl7-cda-cimi-openehr-and-iso13606-approaches-aiming-to-solve/
>

Re: Advantage of ISO

[Gerard Freriks (privé)]

That is correct.

Some NEN.CEN standards are free to obtain in the Netherlands because of a 
contract between the government and the SDO.
Recently the ISO policy is to publish all informative parts of the standard but 
not the normative parts.

Experts nominated by countries have a larger access to full stadard in the 
context of standards creation/maintenance.

It is my opinion that the SDO’s need an other business model such that 
standards are made available for free.


Gerard Freriks
+31 620347088
gf...@luna.nl 
> On 4 sep. 2015, at 21:58, Diego Boscá  wrote:
> 
> There are free ISO specifications, like schematron and a handful more.
> 
> http://standards.iso.org/ittf/PubliclyAvailableStandards/ 
> 
> You can even ask for an ISO norm to be free. In fact asked for ISO 13606 to 
> be free, but received no answer.
> 
> On 04-09-15 19:55, Ian McNicoll wrote:
> I am happy to debate the relevant merits of the ISO vs. open-source 
> approaches recognising
> The one does not exclude the other, I would say.
> 
> But on second thought, does ISO prohibit giving a free license, or publishing 
> the specs for free?
> I am not sure about that.
> I am sure they prohibit publishing their document.
> 
> As is with AOM1.4, it is published as ISO's version by ISO (as part of 
> ISO13606) and it is published  as OpenEHR's version by OpenEHR , so that can 
> be done.
> That both contain the same information.
> 
> It is a bit Kafkaesk, but that is normal when bureaucrats get involved.
> 
> 
> 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

Re: openEHR is open but ISO may offer some other advatages

[Gerard Freriks (privé)]

:-)

Thanks.

GF
> On Sep 4, 2015, at 1:31 PM, Gunnar Klein  wrote:
> 
> I mean the submission of certain openEHR specs to ISO can be made with the 
> present formal status of the Foundation being tied to UCL. To further gain 
> acceptance also by governmental bodies around the globe where people may like 
> openEHR but may hesitate to invest in such an informal body success, I think 
> that a true international organisation without any ties to a specific 
> university may be of some (not big but some) benefit. Also avoid criticisms 
> of the Freriks type.
> 
> Best regards
> 
> Gunnar

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

Re: Advantage of ISO

[Gerard Freriks (privé)]

I agree with you.



> On Sep 4, 2015, at 3:28 PM, pablo pazos  wrote:
> 
> Again: you are explicitly ignoring availability and freedom to use arguments, 
> the main point here...
> 
> This is my last message on this discussion, I'll continue doing something 
> more productive :)
> 
> -- 
> Kind regards,
> Eng. Pablo Pazos Gutiérrez
> http://cabolabs.com 
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Advantage of ISO

[Gerard Freriks (privé)]

It is not a numbers game.

Members/users need to own it.
CEN, ISO, HL7, SNOMED, WHO, all have members that own the IP.
These organizations are real Associations.

Gerard

> On Sep 3, 2015, at 2:41 PM, Seref Arikan <serefari...@kurumsalteknoloji.com> 
> wrote:
> 
> Thanks for your response. 
> Based on this response and another one you gave to Silje, do you think you 
> could give a number of owners of a standard, which you'd consider to be 
> sufficient to make a standard not proprietary? In layman terms: how many 
> owners should a standard have so that you would not call it proprietary? 
> 
> 
> 
> On Thu, Sep 3, 2015 at 8:11 AM, "Gerard Freriks (privé)" <gf...@luna.nl 
> <mailto:gf...@luna.nl>> wrote:
> In the case of CEN, ISO, HL7, SNOMED all members are the owner.
> 
> Gerard
> 
> 
> 
>> On Sep 3, 2015, at 9:00 AM, Seref Arikan <serefari...@kurumsalteknoloji.com 
>> <mailto:serefari...@kurumsalteknoloji.com>> wrote:
>> 
>> Greetings, 
>> Just to clarify my understanding of your understanding of the term: would 
>> you say HL7 and Snomed CT are proprietary ?
> 
> 
> ___
> 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: Advantage of ISO

[Gerard Freriks (privé)]

There is NO relationship between the two: AOM2.0 and IP ownership.

I see no single problem when any actor contributes to the standard.
OpenEHR has made significant contributions, for which we are all grateful.
And I expect that openEHR will continue to do so.

The problem about IP ownership and openEHR is an long standing problem that has 
not been resolved sufficiently, until now.
This is my personal opinion.

Gerard 

PS: Bert: I reacted to an e-mail by Ian, who reacted to one of your e-mails.

> On Sep 3, 2015, at 11:54 PM, Bert Verhees  wrote:
> 
> Gerard, is there a relation between the introduction of AOM2.0, and the 
> coincidence of the renewal process of ISO13606, which has the potential that 
> AOM2.0 will be a part of the renewed ISO13606, and your strong effort to make 
> us aware of your concern about IP risk in using OpenEHR related technologies?
> 
> I ask this because your complaint of OpenEHR in your point not being free 
> must be very old because nothing much has changed in this, except, the (for 
> many) unrelated situations are coming together. Why else would your effort at 
> this very moment be so strong, you spent today, quite a few emails in public 
> space to make this point.
> 
> It must be, that for you, your complaint, must also concern AOM2.0, because 
> it is an OpenEHR related technology released under the same terms as the 
> other specifications.
> 
> In that case, you could consider being glad that AOM2.0 being a part of the 
> renewed 13606. Because that would bring it under ISO, which would make the 
> ISO members be the owner. That would exactly be what you want.
> 
> Or don't you?
> 
> That could only be explained from some other reason, which I don't know.
> 
> I hope you can enlighten us about the reason of your sudden effort of warning 
> us. Why now, why so strong?
> 
> Best regards
> Bert
> 

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

Re: Advantage of ISO

[Gerard Freriks (privé)]

I shared with you my definitions and my argument.
This provided my context.

In principle: definitions are universal in nature and generally applicable in 
many contexts.


Gerard

> On Sep 3, 2015, at 3:33 PM, pazospa...@hotmail.com wrote:
> 
> Definitions are context dependant, but that's not the point... you ignored 
> the true argument about availavility and constraints/freedom to use.
> 
> Sent from my LG Mobile
> -- Original message--
> From: Gerard Freriks (privé)
> Date: Thu, Sep 3, 2015 04:07
> To: For openEHR technical discussions;
> Subject:Re: Advantage of ISO
> I think that definitions are generally valid.
> 
> 
> 
>> On Sep 3, 2015, at 8:38 AM, pablo pazos <pazospa...@hotmail.com 
>> <mailto:pazospa...@hotmail.com>> wrote:
>> 
>> I think that definition doesn't apply to a standard / spec. IMO when we talk 
>> about standards, we focus on the ability to use it and let others use it, 
>> and the constraints / freedoms in that area, not in who is the owner.
>> 
>> -- 
>> Kind regards,
>> Eng. Pablo Pazos Gutiérrez
>> http://cabolabs.com <http://cabolabs.com/es/home>

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

Re: Advantage of ISO

[Gerard Freriks (privé)]

Again.

Answer the question ‘Who owns the specifications of openEHR, looking at the 
quotes I provided?
The answer is:
UCL owns the IP rights and licensing conditions.
Members of, participants in, openEHR gremia, do not.

And that is why I call openEHR specifications proprietary.

According to the definition of ‘open standard’, openEHR is an open Standard
but owned by as single company.

I know for certain that this fact prohibited serious business in some European 
countries, some years ago.
Because of the licensing and dependency on proprietary specifications, the 
artifacts produced were not controllable by the user/customer.
This was their reason, after legal consultation, not to use software based on 
openEHR specifications.

Gerard



> On Sep 3, 2015, at 8:16 PM, Koray Atalag  wrote:
> 
> I think Silje’s explanation is crystal clear on this matter – so what exactly 
> your problem is Gerard with openEHR? Can you give a concrete example where 
> other SDOs you mention are better placed wrt to freedom?
>  
> Cheers,
>  
> -koray

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

Re: Advantage of ISO

[Gerard Freriks (privé)]

I think that definitions are generally valid.



> On Sep 3, 2015, at 8:38 AM, pablo pazos  wrote:
> 
> I think that definition doesn't apply to a standard / spec. IMO when we talk 
> about standards, we focus on the ability to use it and let others use it, and 
> the constraints / freedoms in that area, not in who is the owner.
> 
> -- 
> Kind regards,
> Eng. Pablo Pazos Gutiérrez
> http://cabolabs.com 
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Advantage of ISO

[Gerard Freriks (privé)]

I think that it is NOT a misuse.

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

This a huge difference, don’t you think?

Gerard


> On Sep 3, 2015, at 8:48 AM, Bakke, Silje Ljosland 
>  wrote:
> 
> This is a misuse of the dictionary definition. Using your interpretation, all 
> free/open projects are proprietary unless both IP and trademarks are made 
> Public Domain. Linus Torvalds is the IP copyright holder and trademark owner 
> of Linux, but because it’s released under a free license, it’s not 
> proprietary software. The same goes for the openEHR Foundation and openEHR 
> specs/artifacts/software.
>  
> Kind regards,
> Silje Ljosland Bakke
>  
> Information Architect, RN
> Coordinator, National Editorial Board for Archetypes
> National ICT Norway
> 
> 

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

Re: Advantage of ISO

[Gerard Freriks (privé)]

In the case of CEN, ISO, HL7, SNOMED all members are the owner.

Gerard



> On Sep 3, 2015, at 9:00 AM, Seref Arikan  
> wrote:
> 
> Greetings, 
> Just to clarify my understanding of your understanding of the term: would you 
> say HL7 and Snomed CT are proprietary ?

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

Re: Advantage of ISO

[Gerard Freriks (privé)]

Dear Stef,

About homework:

I’m not contending what you write.
This discussion is about who owns the IP.
And then my points about it are not with spoken.


Gerard 


> On Sep 3, 2015, at 9:26 AM, Stef Verlinden  > wrote:
> 
> Hi Gerard,
> 
> Please stop trolling this list and do your homework. If you would have 
> Googled on ‘open standards’ you would have found the following list of 
> definitions of an open standard on Wiki.
> 
> Please tell us according to which of these definitions OpenEHR isn’t an open 
> standard. If you can’t name one please shut up.
> 
> Cheers, 
> 
> Stef
> 
> ——

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

Re: Advantage of ISO

[Gerard Freriks (privé)]

In this particular case IP is held on specifications archetypes are making use 
of.
It is about ownership of IP of BOTH the Reference Model and the AOM

Gerard

> On Sep 3, 2015, at 10:09 AM, Bert Verhees <bert.verh...@rosa.nl> wrote:
> 
> On 03-09-15 09:07, "Gerard Freriks (privé)" wrote:
>> I think that definitions are generally valid.
> 
> Gerard, I think you know, you be ignorant and warning at the same moment.
> I have good news for you (because ISO13606 is using parts of the AOM) and for 
> all of us.
> There cannot any effective IP be claimed on OpenEHR and related technologies.
> --
> Let me explain:
> 
> There are two kinds of IP
> 
> One is copyright, it is about the literally text of something
> One is patents, it is about the idea worded in the text.
> 
> I don't know any other form of IP, do you Gerard?
> -
> The first does not apply, because the text is given open source
> So, the publisher waives all rights until the end of days.
> -
> Then patents, there may be a hidden patent on OpenEHR related things.
> 
> There a few things important in the case of patents.
> 
> - It may not be based on already existing ideas, that is called prior art.
> - The patent owner is obliged to protect its patent, or else laches defenses 
> are possible. None ever filed a complaint about patent infringement regarding 
> the use of OpenEHR. Now it is too late. Laches defenses are possible after 5 
> years.
> - If the patent-owner lulled you in using a technique, so that you felled 
> safe to use it, he cannot claim afterwards IP on that.
> (Under the doctrine of “equitable estoppel”, the accused infringer must have 
> relied on the patentee’s assurance or non-enforcement in choosing to continue 
> infringing. The key issue is whether the accused was lulled into a false 
> sense of security and evidence that the accused detrimentally relied upon it.)
> 
> http://www.lawabel.com/patent-damages-laches-and-equitable-estoppel/ 
> <http://www.lawabel.com/patent-damages-laches-and-equitable-estoppel/>
> 
> So we can safely say that, even if there are patents on OpenEHR, they can 
> never be effected anymore.
> Not even on a new version of the Reference Model, because that will come very 
> close to prior art.
> --
> But still I think that the OpenEHR-organization should take more action to 
> fightr these rumors.
> 
> 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: Advantage of ISO

[Gerard Freriks (privé)]

What do I misunderstand?

The definition of ‘proprietary’ according to GOOGLE  is clear.
proprietary
prəˈprʌɪət(ə)ri/
adjective
adjective: proprietary
1. 
relating to an owner or ownership.
"the company has a proprietary right to the property"
behaving as if one owned something or someone.
"he looked about him with a proprietary air"
2. 
(of a product) marketed under and protected by a registered trade name.
"proprietary brands of insecticide"
Origin

late Middle English (as a noun denoting a member of a religious order who held 
property): from late Latin proprietarius ‘proprietor’, from proprietas (see 
property 
).

On the openEHR website we all can read about the Legal Status.
And that is clear, also.
OpenEHR specs are owned by the company that is owned by UCL, only.



Gerard

> On Sep 3, 2015, at 2:07 AM, Ian McNicoll  wrote:
> 
> Hi Bert,
> 
> I am certainly conscious of rumours. Some of these are due to general 
> suspicion of open source licensing (and we can, I think, do more to alleviate 
> this)  but I am afraid some of anxiety is also caused by inaccurate and 
> misleading information "openEHR is proprietary",  regularly stated by a small 
> number of individuals. I have had to ask for these to be corrected in a 
> number of documents e.g. The SemanticHealthNet report where it was agreed by 
> the principal authors, including Dipak, to be incorrect.
> 
> Since a significant number of companies and national organisations now make 
> use of openEHR specifications or artefacts, these statements are being 
> regarded as commercially hostile and the Foundation Boards both agree that 
> legal action should now be taken where the authors are not prepared to 
> promptly correct this inaccuracy.
> 
> Leaving that aside. I am not convinced that ISO is a good home for openEHR. 
> The specifications, development and revision process in ISO remain completely 
> closed and quite at odds withopenEHR principles but I would be interested in 
> other's views. 
> 
> I do think that some sort of association with a formal standards body would 
> help alleviate some of the anxieties you mention (though these are imaginary) 
> but I am not sure that ISO would be my first choice as it is currently 
> constructed. I will raise the issue of whether to submit AOM2 with the 
> Management Board.
> 
> I am interested in other people's opinions.
> 
> Ian
> 
> 
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com 
> twitter: @ianmcnicoll
> 
> 
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org 
> 
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
> 
> On 1 September 2015 at 16:48, Bert Verhees  > wrote:
> On 01-09-15 17:16, Bert Verhees wrote:
> I have written a text (reply to Erik) in Stackoverflow, describing why it 
> will be good for OpenEHR if AOM2.0 will become an ISO-standard in the context 
> of ISO13606 renewal.
> 
> http://stackoverflow.com/questions/32010122/are-the-hl7-fhir-hl7-cda-cimi-openehr-and-iso13606-approaches-aiming-to-solve/
>  
> 
>  
> 
> I must add, it is not that I suspect anyone of having secret IP on OpenEHR.
> I have no reason to suspect this.
> 
> But I know people who have such suspicions, and having the AOM-part as an ISO 
> standard, surely will fight these rumors.
> 
> I think it will help OpenEHR-implementations to have more customers.
> 
> 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

Re: difference and relationship between openEHR and EN13606

[Gerard Freriks (privé)]

Dear Pablo,

According to the scope statement: the 13606 is for the creation of the 
EHR-EXtract for communication between IT-systems
and
for the definition of the Information Viewpoint in Interfaces with system 
services.

Gerard

Gerard Freriks
+31 620347088
gf...@luna.nl mailto:gf...@luna.nl
 On 26 aug. 2015, at 13:50, pazospa...@hotmail.com wrote:
 
 Hi, 
 
 I would say that the main difference is that 13606 is for data communication 
 and openEHR is for EHR architecture, both based on archerypes.
 
 For detailed differences just look at both information models, you will see 
 that 13606 IM is much simple.
 
 About the specs, 13606 has 5 chapters, including communication and 
 security, and openEHR specs don't have those.
 
 The best way of knowing the differences is just to download the specs of both 
 and compare them.
 
 Hope that helps,
 Cheers,
 Pablo.
 
 Sent from my LG Mobile
 -- Original message--
 From: 王海生
 Date: Wed, Aug 26, 2015 06:14
 To: openehr-technical@lists.openehr.org 
 mailto:openehr-technical@lists.openehr.org;
 Subject:difference and relationship between openEHR and EN13606
 dear all ,
 how could i  explain to someone difference and relationship between 
 openEHR and EN13606 
 thx 
 --
 王海生
 15901958021 tel:15901958021
 
 
 
 夏日畅销榜大牌美妆只要1元 
 http://r.mail.163.com/r.jsp?url=http%3A%2F%2F1.163.com%2Fhd%2Foneact%2Fhdframe.do%3Fid%3D21%26from%3Dfooter_beautysign=817593681_r_ignore_statId=7_13_79_48_r_ignore_uid=n...@163.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: difference and relationship between openEHR and EN13606

[Gerard Freriks (privé)]

Hi,

I must repeat the scope of 13606 verbatim once more.
It is NOT only for messaging but also for Interfaces



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



Scope
This standard is for the communication of part or all of the electronic health 
record (EHR) of a single identified subject of care between EHR systems, or 
between EHR systems and a centralised EHR data repository. 

It may also be used for EHR communication between an EHR system or repository 
and clinical applications or middleware components (such as decision support 
components) that need to access or provide EHR data. 

This standard will predominantly be used to support the direct care given to 
identifiable individuals, or to support population monitoring systems such as 
disease registries and public health surveillance. Uses of health records for 
other purposes such as teaching, clinical audit, administration and reporting, 
service management, research and epidemiology, which often require 
anonymisation or aggregation of individual records, are not the focus of this 
standard but such secondary uses might also find the standard useful. 

This Part 1 of the multipart standard is an Information Viewpoint specification 
as defined by the Open Distributed Processing – Reference model (ISO/IEC 
10746). This standard is not intended to specify the internal architecture or 
database design of EHR systems. 






 On 26 aug. 2015, at 14:57, Sebastian Garde 
 sebastian.ga...@oceaninformatics.com wrote:
 
 I'd agree with Ian here. 
 While both could possibly support AQL, the difference I see is in intent, 
 scope and actual implementation.
 As Gerard says, 13606's main aim is to communicate between IT-systems and for 
 this, AQL may not be quite as fundamental as it is to openEHR.
 
 Sebastian
 
 
 On 26.08.2015 14:44, Ian McNicoll wrote:
 Hi Bert,
 
 I would leave it with: AQL is an archetype bound query language, and every 
 system which is build on archetypes is able to implement AQL.
 
 That is fair enough but we were asked to characterise the differences 
 between 13606 and openEHR and I am comfortable that the actual and formal 
 adoption of AQL is one of thosedifferences.
 
 AQL is on the openEHR specifications roadmap but AFAIK this is not the case 
 for 13606. Of course that does not stop 13606 vendors implementing AQL but 
 in terms of actual differences between the 2 communities the adoption, or 
 intention to adopt AQL seems (from the outside) somewhat different both at a 
 practical and formal level.
 
 Although AQL adoption in the openEHR community is far from universal, most 
 of the vendors/developers that I have spoken to see it as something they 
 want to implement, particularly as GDL is somewhat dependent on AQL.
 
 I am just trying to ascertain if there is similar enthusiasm/intention 
 amongst 13606 vendors, or if AQL forms part of the current 13606 refresh 
 discussions.
 
 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  
 mailto:ian.mcnic...@openehr.orgian.mcnic...@openehr.org 
 mailto:ian.mcnic...@openehr.org
 Director, freshEHR Clinical Informatics Ltd.
 Director, HANDIHealth CIC
 Hon. Senior Research Associate, CHIME, UCL
 
 On 26 August 2015 at 13:28, Bert Verhees bert.verh...@rosa.nl 
 mailto:bert.verh...@rosa.nl wrote:
 On 26-08-15 14:23, Ian McNicoll wrote:
 but am not aware of any non-openEHR
 implementations
 Is there a Xhosa implementation of 13606 or OpenEHR?
 
 Does that mean OpenEHR or 13606 are not able to support Xhosa?
 
 I would leave it with: AQL is an archetype bound query language, and every 
 system which is build on archetypes is able to implement AQL.
 
 
 ___
 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
 -- 
  
 Dr. Sebastian Garde
 Dr. sc. hum., Dipl.-Inform. Med, FACHI
 Ocean Informatics
 
 Skype: gardeseb
 
 
   https://www.avast.com/antivirus   
 Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. 
 www.avast.com https://www.avast.com/antivirus
 ___
 openEHR-technical mailing list
 openEHR-technical@lists.openehr.org
 http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

___

Re: difference and relationship between openEHR and EN13606

[Gerard Freriks (privé)]

Hi,

Next week we will meet in Brussels and discuss the proposals, discussion papers 
by the various working parties.
I think that the RM and data types will be simplified.
leaving semantics to be dealt with at the archetype level using standardised 
archetype patterns.
(participations, demographics, and things like ranges and more)

On behalf of the EN13606  Association I take part in the CIMI working group.
CIMI will help create archetype patterns.
CIMI models will be able to be converted to EN13606 artefacts.
And all in spite of the fact that CIMI has a very simple and strange RM derived 
from 13606-1. (At least that is the way I look at it)

The strange thing being the fact that they have defined a ‘Super ENTRY’ class 
that can contain the ‘normal’ ENTRY class.
They designed this because of the need to model for instance panels as one 
entity and each of its components.
(I’m of the opinion that the present 13606 RM can deal with all the CIMI 
requirements. This is how I create panels usually.)

 

Gerard Freriks
+31 620347088
gf...@luna.nl mailto:gf...@luna.nl
 On 26 aug. 2015, at 17:49, Erik Sundvall erik.sundv...@liu.se wrote:
 
 Hi!
 
 Where can one find proposals/diagrams describing the refreshed RM (reference 
 model) in the new 13606 revision? Will 13606 keep using the old data types or 
 harmonize more with CIMI or OpenEHR?
 
 Is there now consensus/majority regarding using ADL/AOM 2.0 for 13606? If so, 
 great!
 
 When it comes to simplifying the RM (or perhaps moving complexity to 
 another meta/design-pattern layer) I think CIMI has gone further than 13606. 
 Are there any plans of aligning 13606 with CIMI?
 
 //Erik Sundvall 

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

Re: difference and relationship between openEHR and EN13606

[Gerard Freriks (privé)]

We are in agreement, then.  :-)

Gerard Freriks
+31 620347088
gf...@luna.nl mailto:gf...@luna.nl
 On 26 aug. 2015, at 17:06, Ian McNicoll i...@freshehr.com wrote:
 
 Hi Gerard,
 
 Agreed - I was using messaging loosely - 'interfacing between systems' is 
 better.
 
 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 26 August 2015 at 15:04, Gerard Freriks (privé) gf...@luna.nl 
 mailto:gf...@luna.nl wrote:
 Hi,
 
 I must repeat the scope of 13606 verbatim once more.
 It is NOT only for messaging but also for Interfaces
 
 
 
 Gerard Freriks
 +31 620347088 tel:%2B31%20620347088
 gf...@luna.nl mailto:gf...@luna.nl
 
 
 
 Scope
 This standard is for the communication of part or all of the electronic 
 health record (EHR) of a single identified subject of care between EHR 
 systems, or between EHR systems and a centralised EHR data repository. 
 
 It may also be used for EHR communication between an EHR system or repository 
 and clinical applications or middleware components (such as decision support 
 components) that need to access or provide EHR data. 
 
 This standard will predominantly be used to support the direct care given to 
 identifiable individuals, or to support population monitoring systems such as 
 disease registries and public health surveillance. Uses of health records for 
 other purposes such as teaching, clinical audit, administration and 
 reporting, service management, research and epidemiology, which often require 
 anonymisation or aggregation of individual records, are not the focus of this 
 standard but such secondary uses might also find the standard useful. 
 
 This Part 1 of the multipart standard is an Information Viewpoint 
 specification as defined by the Open Distributed Processing – Reference model 
 (ISO/IEC 10746). This standard is not intended to specify the internal 
 architecture or database design of EHR systems. 
 
 
 
 
 
 
 On 26 aug. 2015, at 14:57, Sebastian Garde 
 sebastian.ga...@oceaninformatics.com 
 mailto:sebastian.ga...@oceaninformatics.com wrote:
 
 I'd agree with Ian here. 
 While both could possibly support AQL, the difference I see is in intent, 
 scope and actual implementation.
 As Gerard says, 13606's main aim is to communicate between IT-systems and 
 for this, AQL may not be quite as fundamental as it is to openEHR.
 
 Sebastian
 
 
 On 26.08.2015 14:44, Ian McNicoll wrote:
 Hi Bert,
 
 I would leave it with: AQL is an archetype bound query language, and every 
 system which is build on archetypes is able to implement AQL.
 
 That is fair enough but we were asked to characterise the differences 
 between 13606 and openEHR and I am comfortable that the actual and formal 
 adoption of AQL is one of those  differences.
 
 AQL is on the openEHR specifications roadmap but AFAIK this is not the case 
 for 13606. Of course that does not stop 13606 vendors implementing AQL but 
 in terms of actual differences between the 2 communities the adoption, or 
 intention to adopt AQL seems (from the outside) somewhat different both at 
 a practical and formal level.
 
 Although AQL adoption in the openEHR community is far from universal, most 
 of the vendors/developers that I have spoken to see it as something they 
 want to implement, particularly as GDL is somewhat dependent on AQL.
 
 I am just trying to ascertain if there is similar enthusiasm/intention 
 amongst 13606 vendors, or if AQL forms part of the current 13606 refresh 
 discussions.
 
 Ian
 
 
 
 
 Dr Ian McNicoll
 mobile +44 (0)775 209 7859 tel:%2B44%20%280%29775%20209%207859
 office +44 (0)1536 414994 tel:%2B44%20%280%291536%20414994
 skype: ianmcnicoll
 email: i...@freshehr.com mailto:i...@freshehr.com
 twitter: @ianmcnicoll
 
 
 Co-Chair, openEHR Foundation  
 mailto:ian.mcnic...@openehr.orgian.mcnic...@openehr.org 
 mailto:ian.mcnic...@openehr.org
 Director, freshEHR Clinical Informatics Ltd.
 Director, HANDIHealth CIC
 Hon. Senior Research Associate, CHIME, UCL
 
 On 26 August 2015 at 13:28, Bert Verhees bert.verh...@rosa.nl 
 mailto:bert.verh...@rosa.nl wrote:
 On 26-08-15 14:23, Ian McNicoll wrote:
 but am not aware of any non-openEHR
 implementations
 Is there a Xhosa implementation of 13606 or OpenEHR?
 
 Does that mean OpenEHR or 13606 are not able to support Xhosa?
 
 I would leave it with: AQL is an archetype bound query language, and every 
 system which is build on archetypes is able to implement AQL.
 
 
 ___
 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

Re: difference and relationship between openEHR and EN13606

[Gerard Freriks (privé)]

That is good to know.

Gerard

Gerard Freriks
+31 620347088
gf...@luna.nl mailto:gf...@luna.nl
 On 26 aug. 2015, at 16:42, pablo pazos pazospa...@hotmail.com wrote:
 
 Dear Gerard, IMO communication includes the interfaces, I didn't excluded 
 them :D
 
 -- 
 Kind regards,
 Eng. Pablo Pazos Gutiérrez
 http://cabolabs.com http://cabolabs.com/es/home http://twitter.com/ppazos
 
 Subject: Re: difference and relationship between openEHR and EN13606
 From: gf...@luna.nl mailto:gf...@luna.nl
 Date: Wed, 26 Aug 2015 14:03:18 +0200
 To: openehr-technical@lists.openehr.org 
 mailto:openehr-technical@lists.openehr.org
 
 Dear Pablo,
 
 According to the scope statement: the 13606 is for the creation of the 
 EHR-EXtract for communication between IT-systems
 and
 for the definition of the Information Viewpoint in Interfaces with system 
 services.
 
 Gerard
 
 Gerard Freriks
 +31 620347088
 gf...@luna.nl mailto:gf...@luna.nl
 On 26 aug. 2015, at 13:50, pazospa...@hotmail.com 
 mailto:pazospa...@hotmail.com wrote:
 
 Hi, 
 
 I would say that the main difference is that 13606 is for data communication 
 and openEHR is for EHR architecture, both based on archerypes.
 
 For detailed differences just look at both information models, you will see 
 that 13606 IM is much simple.
 
 About the specs, 13606 has 5 chapters, including communication and 
 security, and openEHR specs don't have those.
 
 The best way of knowing the differences is just to download the specs of both 
 and compare them.
 
 Hope that helps,
 Cheers,
 Pablo.
 
 Sent from my LG Mobile
 -- Original message--
 From: 王海生
 Date: Wed, Aug 26, 2015 06:14
 To: openehr-technical@lists.openehr.org 
 mailto:openehr-technical@lists.openehr.org;
 Subject:difference and relationship between openEHR and EN13606
 dear all ,
 how could i  explain to someone difference and relationship between 
 openEHR and EN13606 
 thx 
 --
 王海生
 15901958021 
 
 
 
 夏日畅销榜大牌美妆只要1元 
 http://r.mail.163.com/r.jsp?url=http://1.163.com/hd/oneact/hdframe.do?id%3D21%26from%3Dfooter_beautysign=817593681_r_ignore_statId=7_13_79_48_r_ignore_uid=nt%40163.com___
 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.orghttp://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

CRUD Restlet

[Gerard Freriks (privé)]

Niet een slecht advies: Kijken bij FHIR van HL7

GF

Gerard Freriks
+31 620347088
gfrer at luna.nl mailto:gfrer at luna.nl
 On 19 jan. 2015, at 11:29, Diego Bosc? yampeku at gmail.com wrote:
 
 I will just add that if you are making a server you probably want to
 take a look and how FHIR does things. They have some pretty cool ideas
 for common problems that you can probably reuse (e.g. using atom for
 query responses)

-- next part --
An HTML attachment was scrubbed...
URL: 
http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150119/6a442f1d/attachment.html