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  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&toc=nofloat 
> <http://dmd.medicines.org.uk/DesktopDefault.aspx?VMP=318421004&toc=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  <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 arbitra

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 <mailto: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 <mailto: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 <mailto: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  
> <https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjkjrG8hrTMAhWEWxQKHc_dDsIQFggcMAA&url=https%3A%2F%2Fbfo.googlecode.com%2Fsvn%2Ftrunk%2Fdocs%2Fbfo2-reference%2FBFO2-Reference.docx&usg=AFQjCNFaciudhkU555FkqpQscrO0rRJUmQ&sig2=wWITHga_L6Vp1RTU4lvEEw&bvm=bv.120853415,d.d24>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-i-heather-leslie>
>>  
>> https://www.linkedin.com/pulse/journey-interoperability-part-ii-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 
>> shoul

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 <mailto: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 <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 29 April 2016 at 15:45, Bert Verhees  <mailto:bert.verh...@rosa.nl>> 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 mea

Re: rm_type_name for the DV_DURATIONs primitive object in XML

[Gerard Freriks (privé)]

What is EN13606 specifying?
What about in the new release?

In my opinion.
Duration is a derived attribute of an episode of a process.
It is expressed in absolute terms in units of measurement that express any 
number of time units.
Or in relative terms in relation to an other episode (process) or point in 
time. Plus a relationship between the two.

Point in time can be absolute: expressed as a point on the time line with a 
defined granularity
Or relative to an other point in time or an episode (process) plus the 
relationship between the two.

In archetype models we need an archetype pattern to specify all these possible 
patterns.
What I describe is not really a Data Type, but a complex archetype pattern.

I only need the point in time data type
and a standard way to define attributes of any episode(process).



Gerard Freriks
+31 620347088
gf...@luna.nl <mailto:gf...@luna.nl>
> On 15 mrt. 2016, at 17:01, Diego Boscá  wrote:
> 
> To make things worse, in the XML Schema DV_DURATION contains an
> Iso8601Duration, which in the end is an string with a regex
> 
> 2016-03-15 16:43 GMT+01:00 Sebastian Garde
>  <mailto:sebastian.ga...@oceaninformatics.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é)]

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  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é)"  <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 
> gf...@luna.nl <mailto:gf...@luna.nl>
>> On 3 sep. 2015, at 02:07, Ian McNicoll > <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 
>> 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 1 September 2015 at 16:48, Bert Verhees > <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/
>>  
>> <http://stackoverflow.com/questions/32010122/are-the-hl7-fhir-hl7-cda-cimi-openehr-and-iso13606-approaches-aiming-to-solve/>
>>  
>> 
>> I must add, it i

Re: Advantage of ISO

[Gerard Freriks (privé)]

I will consider this.

Gerard

Gerard Freriks
+31 620347088
gf...@luna.nl <mailto: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,

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 <mailto: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 <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  <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/
>  
> <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 
> <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é)]

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 <mailto: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/ 
> <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 
> <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é)]

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: 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 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 > <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é)]

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

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  
> 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é)"  <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 > <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é)]

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

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

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

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

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

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

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  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  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é)"  <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 
> 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 
>> > <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 
>>> 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.org>ian.mcnic...@openehr.org 
>>> <mailto:ian.mcnic...@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  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_beauty&sign=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.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

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 
>  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.org>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 13:28, Bert Verhees > <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.ope

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 
> 
> 
> 
> 夏日畅销榜大牌美妆只要1元 
> <http://r.mail.163.com/r.jsp?url=http%3A%2F%2F1.163.com%2Fhd%2Foneact%2Fhdframe.do%3Fid%3D21%26from%3Dfooter_beauty&sign=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

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

Postulate: DV_QUANTITY should be modelled with fewest possible units

[Gerard Freriks]

Dear all,

Magnitude is not the same as Units of Measurement.
Units of Measurement are not the same as Magnitude.

Gerard

Gerard Freriks
+31 620347088
gfrer at luna.nl <mailto:gfrer at luna.nl>
> On 17 nov. 2014, at 13:47, Ian McNicoll  oceaninformatics.com> wrote:
> 
> Hi Thomas,
> 
> RM function to retrieve a magnitude expressed as a particular unit.
> 
> from my previous email ...
> 
> I think we could add something at reference model level to say give me
> this quantity in 'x' units, performing the conversion at server level
> where possible or return null. This could also be supported in AQL
> since it would just be another RM attribute/function?
> 
> magnitude.inUnit['mg']
> 
> I think this is, roughly speaking, what FHIR is doing
> 
> Ian

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141117/c1c28e6e/attachment.html>

openEHR-technical Digest, Vol 33, Issue 23

[Gerard Freriks]

I prefer to deal in the Reference Model with the documentation and archiving 
aspects.
Any Composition needs to be signed, irrespective of the content.
And that signing on occasion is by multiple persons, in different roles.

When specific parts of the data as defined by the Composition need to be 
signed-oof, than that is a different matter.

And signing off the Composition as artefact (Archetype) is a different matter 
again.

Gerard Freriks
+31 620347088
gfrer at luna.nl <mailto:gfrer at luna.nl>
> On 15 nov. 2014, at 10:56, Ian McNicoll  wrote:
> 
> Hi William,
> 
> I don't really agree with your suggested approach. The specific
> requirement is to be able to formally sign or counter-sign the entire
> document, possibly for reasons of medico-legal responsibility as Dipak
> has described, or because specific requests or orders must have senior
> sign-off.  The majority of documents will have no attestations but the
> potential need is universal, whilst orthogonal to the type of document
> or content. This makes it entirely sensible to handle at RM level.
> 
> Attestation is quite different from the ideas of evidence, use of
> guidelines etc that you seem to be talking about.
> 
> Ian
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: ian at freshehr.com <mailto:ian at freshehr.com>
> twitter: @ianmcnicoll
> 
> Director, freshEHR Clinical Informatics
> Director, openEHR Foundation
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141115/0bfc528d/attachment.html>

Defining multiple constraint bindings in AOM/ADL 1.4

[Gerard Freriks]

> On 31 okt. 2014, at 08:39, David Moner  wrote:
> 
> I will explain it in another way.
> 
> ac codes are used as "placeholder constraints", i.e. a kind of link to a 
> query or subset in a terminological systems that defines the possible 
> instance values of a coded attribute.
> 
> My question was: Is it needed to be always a link to a subset? Cannot we use 
> ac to define bindings to specific terminological codes explicitly 
> enumerated, without the need of defining a subset in the terminological 
> system in advance?

Use case: to define an ?ad-hoc? list of codes that might apply and from which 
one can be choosen without the need to use the terminology service?

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

Texts about transforming between openEHR and other formalisms

[Gerard Freriks]

Hi,

At last I can use copies for my own collection of articles


Gerard Freriks
+31 620347088
gfrer at luna.nl

On 25 sep. 2014, at 10:50, Diego Bosc?  wrote:

> I have the same doubts as Ian about which kinds of transformations you
> are looking for, so I'll give you a summary :)
> 
> 
> Here we have done several works regarding data instance transformation
> based on archetypes:
> 
> - Maldonado, J. A., Moner, D., Tom?s, D., ?ngulo, C., Robles, M., &
> Fern?ndez, J. T. (2007). Framework for clinical data standardization
> based on archetypes. Studies in health technology and informatics,
> 129(1), 454.
> 
> - Moner, D., Maldonado, J. A., Bosca, D., Fern?ndez, J. T., Angulo,
> C., Crespo, P., ... & Robles, M. (2006, August). Archetype-based
> semantic integration and standardization of clinical data. In
> Engineering in Medicine and Biology Society, 2006. EMBS'06. 28th
> Annual International Conference of the IEEE (pp. 5141-5144). IEEE.
> 
> - Moner, D., Maldonado, J. A., Bosc?, D., Angulo, C., Robles, M.,
> P?rez, D., & Serrano, P. (2010, May). CEN EN13606 normalisation
> framework implementation experiences. In Seamless Care, Safe Care: The
> Challenges of Interoperability and Patient Safety in Health Care:
> Proceedings of the EFMI Special Topic Conference, June 2-4, 2010,
> Reykjavik, Iceland (Vol. 155, p. 136). IOS Press.
> 
> - Maldonado, J. A., Moner, D., Bosca, D., Angulo, C., Marco, L., Reig,
> E., & Robles, M. (2011, July). Concept-based exchange of healthcare
> information: The LinkEHR approach. In Healthcare Informatics, Imaging
> and Systems Biology (HISB), 2011 First IEEE International Conference
> on (pp. 150-157). IEEE.
> 
> - Mart?nez Costa, C., Men?rguez-Tortosa, M., & Fern?ndez-Breis, J. T.
> (2011). Clinical data interoperability based on archetype
> transformation. Journal of biomedical informatics, 44(5), 869-880.
> 
> - Moner, D., Moreno, A., Maldonado, J. A., Robles, M., & Parra, C.
> (2012, August). Using archetypes for defining CDA templates. In MIE
> (pp. 53-57).
> 
> - Moner D. LinkEHR Studio: a tool for archetype-based data
> transformations. Arctic Conference 2014
> (http://vimeo.com/channels/764149)
> 
> 
> Model transformations:
> 
> - Mart?nez-Costa, C., Men?rguez-Tortosa, M., & Fern?ndez-Breis, J. T.
> (2010). An approach for the semantic interoperability of ISO EN 13606
> and OpenEHR archetypes. Journal of biomedical informatics, 43(5),
> 736-746.
> 
> - Mart?nez-Costa, C., Bosca, D., Legaz-Garc?a, M. C., Tao, C.,
> Fern?ndez, B. J., Schulz, S., & Chute, C. G. (2012). Isosemantic
> Rendering of Clinical Information Using Formal Ontologies and RDF.
> Studies in health technology and informatics, 192, 1085-1085.
> 
> - Lezcano, L., Sicilia, M. A., & Rodr?guez-Solano, C. (2011).
> Integrating reasoning and clinical archetypes using OWL ontologies and
> SWRL rules. Journal of biomedical informatics, 44(2), 343-353.
> 
> - Detailed Clinical Models to facilitate inter-standard
> interoperability of data types. Diego Bosc?, Jos? Alberto Maldonado,
> David Moner, Montserrat Robles. XXIII International Conference of the
> European Federation for Medical Informatics (MIE 2011), Oslo;
> Proceedings (2011)
> 
> 
> GUI
> 
> - Men?rguez-Tortosa, M., Mart?nez-Costa, C., & Fern?ndez-Breis, J. T.
> (2012). A generative tool for building health applications driven by
> iso 13606 archetypes. Journal of medical systems, 36(5), 3063-3075.
> 
> - Brass, A., Moner, D., Hildebrand, C., & Robles, M. (2010).
> Standardized and flexible health data management with an archetype
> driven EHR system (EHRflex). Studies in health technology and
> informatics, 155, 212.
> 
> 
> One about combining all the above
> 
> - Maldonado, J. A., Costa, C. M., Moner, D., Men?rguez-Tortosa, M.,
> Bosc?, D., Mi?arro Gim?nez, J. A., ... & Robles, M. (2012). Using the
> ResearchEHR platform to facilitate the practical application of the
> EHR standards. Journal of biomedical informatics, 45(4), 746-762.
> 
> 
> Transformations for the use of archetypes for clinical guidelines
> 
> - Marcos, M., Maldonado, J. A., Mart?nez-Salvador, B., Moner, D.,
> Bosc?, D., & Robles, M. (2011). An archetype-based solution for the
> interoperability of computerised guidelines and electronic health
> records. In Artificial Intelligence in Medicine (pp. 276-285).
> Springer Berlin Heidelberg.
> 
> (there are plenty of papers on the modeling of clinical guidelines in openEHR)
> 
> 
> Transformations of archetypes for the validation of clinical data
> 
> - Pfeiffer, Klaus, Georg Duftschmid, and Christoph Rinner. ?Validating
> EHR Documents: Automatic Schematron Generation Usi

Alignment of languages and translations in templates (was: Invalid language codes in languages codeset)

[Gerard Freriks]

imo

1- Slots need to 'point at? archetypes by Name of the Archetype and NOT the 
file name. Plus something else ?
2- All Nodes in any archetype never derive any meaning from the text of the 
label attached the Node and thereby can be language independent. Archetypes 
written in different languages can be used at will. This is possible only when ?
3- Node names derive their identity (meaning) from a code from a predefined 
code set.
4- In addition we must be able to ?point at? other archetypes using unique 
identifiers, or a construct using generated Hash-codes for each unique 
archetype.


Gerard Freriks

+31 620347088
gfrer at luna.nl

On 2 apr. 2014, at 13:27, Diego Bosc?  wrote:

> I repost this discussion from the java implementation list, I think it could 
> be interesting to get feedback from the general implementers community.
> 
> -- Forwarded message --
> From: Thomas Beale 
> Date: 2014-04-02 12:51 GMT+02:00
> Subject: Re: Invalid language codes in languages codeset
> To: ref_impl_java at lists.openehr.org
> 
> 
> 
> I have not been following closely here, but I think the general approach 
> should be that you perform a design time validation pass, that reports things 
> like language incompatibility, i.e. never let there be ambiguity close to 
> runtime. 
> 
> The question then is: how does the validation of this particular thing work? 
> The first thing to note is that the possible slot fillers of a given slot in 
> an archetype are only those that are found in the current working set of 
> archetypes, not some theoretical maximum set (e.g. all of CKM or all Spanish 
> MOH etc). So, within a chosen working set, validation on language 
> compatibilty can probably only occur at the point of operational template 
> (OPT) generation, i.e. where the user specifies which actual languages and 
> terminologies (for terminology bindings) should be used, then a tool could 
> run a relatively simple test to see that all archetypes in the working set do 
> have translations in the chosen language(s). 
> 
> One could imagine more complex validations to do with figuring out of all 
> slot-filling archetypes have any language in common with slot-defining 
> archetypes, but I don't think this is useful. 
> 
> I have no check like this in the ADL Workbench yet, so I am interested to 
> know what others think it should be. 
> 
> We don't really have a proper definition of 'working set' or other possible 
> 'sets' of archetypes, but we probably need them. Getting a common definition 
> means everyone agreeing on a standard workflow for archetype development, and 
> possible ideas like defining a 'deployment set' from a larger 'working set', 
> or maybe a publisher's 'release set'.
> 
> - thomas
> 
> 
> On 02/04/2014 11:33, Diego Bosc? wrote:
>> Just today we had another interesting discussion on a related topic
>> about languages, translations, and slot solving.
>> The problem comes when you have an archetype whose original language
>> is different from the one that you are solving the slot with. There
>> are several alternatives, but seems that there is no 'perfect' one.
>> 
>> There is always the possibility of taking the original language of the
>> solved slot archetype and just add it to the original archetype as a
>> translation, marking the strings in the other languages in some way.
>> 
>> This is related to the languages codes as we could assume that a slot
>> with an 'en-gb' can be safely placed in a 'en' archetype and reuse all
>> the texts and descriptions. The problem comes the other way around
>> (can we assume that a 'en' slot can be safely placed in a 'en-gb'
>> archetype?).
>> 
>> Even if you have the same language in both archetypes, we have to
>> consider if a translation from a slot has the same validity to be
>> included in the original language descriptions of an given archetype
>> (In theory, all translations should be made from the original
>> language, and if the original language was another one, can we assure
>> that the meaning is the same as the original?)
>> 
>> Anyone of the list has been dealing with this problem? Which solutions
>> have you adopted for your tools/systems?
>> 
>> 
> 
> -- 
>  Thomas Beale
> Chief Technology Officer 
> +44 7792 403 613   Specification Program, openEHR 
> Honorary Research Fellow, UCL 
> Chartered IT Professional Fellow, BCS 
> Health IT blog   
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at lists

Alignment of languages and translations in templates (was: Invalid language codes in languages codeset)

[Gerard Freriks]

imo

1- Slots need to 'point at? archetypes by Name of the Archetype and NOT the 
file name. Plus something else ?
2- All Nodes in any archetype never derive any meaning from the text of the 
label attached the Node and thereby can be language independent. Archetypes 
written in different languages can be used at will. This is possible only when ?
3- Node names derive their identity (meaning) from a code from a predefined 
code set.
4- In addition we must be able to ?point at? other archetypes using unique 
identifiers, or a construct using generated Hash-codes for each unique 
archetype.


Gerard Freriks

+31 620347088
gfrer at luna.nl

On 2 apr. 2014, at 13:27, Diego Bosc?  wrote:

> I repost this discussion from the java implementation list, I think it could 
> be interesting to get feedback from the general implementers community.
> 
> -- Forwarded message --
> From: Thomas Beale 
> Date: 2014-04-02 12:51 GMT+02:00
> Subject: Re: Invalid language codes in languages codeset
> To: ref_impl_java at lists.openehr.org
> 
> 
> 
> I have not been following closely here, but I think the general approach 
> should be that you perform a design time validation pass, that reports things 
> like language incompatibility, i.e. never let there be ambiguity close to 
> runtime. 
> 
> The question then is: how does the validation of this particular thing work? 
> The first thing to note is that the possible slot fillers of a given slot in 
> an archetype are only those that are found in the current working set of 
> archetypes, not some theoretical maximum set (e.g. all of CKM or all Spanish 
> MOH etc). So, within a chosen working set, validation on language 
> compatibilty can probably only occur at the point of operational template 
> (OPT) generation, i.e. where the user specifies which actual languages and 
> terminologies (for terminology bindings) should be used, then a tool could 
> run a relatively simple test to see that all archetypes in the working set do 
> have translations in the chosen language(s). 
> 
> One could imagine more complex validations to do with figuring out of all 
> slot-filling archetypes have any language in common with slot-defining 
> archetypes, but I don't think this is useful. 
> 
> I have no check like this in the ADL Workbench yet, so I am interested to 
> know what others think it should be. 
> 
> We don't really have a proper definition of 'working set' or other possible 
> 'sets' of archetypes, but we probably need them. Getting a common definition 
> means everyone agreeing on a standard workflow for archetype development, and 
> possible ideas like defining a 'deployment set' from a larger 'working set', 
> or maybe a publisher's 'release set'.
> 
> - thomas
> 
> 
> On 02/04/2014 11:33, Diego Bosc? wrote:
>> Just today we had another interesting discussion on a related topic
>> about languages, translations, and slot solving.
>> The problem comes when you have an archetype whose original language
>> is different from the one that you are solving the slot with. There
>> are several alternatives, but seems that there is no 'perfect' one.
>> 
>> There is always the possibility of taking the original language of the
>> solved slot archetype and just add it to the original archetype as a
>> translation, marking the strings in the other languages in some way.
>> 
>> This is related to the languages codes as we could assume that a slot
>> with an 'en-gb' can be safely placed in a 'en' archetype and reuse all
>> the texts and descriptions. The problem comes the other way around
>> (can we assume that a 'en' slot can be safely placed in a 'en-gb'
>> archetype?).
>> 
>> Even if you have the same language in both archetypes, we have to
>> consider if a translation from a slot has the same validity to be
>> included in the original language descriptions of an given archetype
>> (In theory, all translations should be made from the original
>> language, and if the original language was another one, can we assure
>> that the meaning is the same as the original?)
>> 
>> Anyone of the list has been dealing with this problem? Which solutions
>> have you adopted for your tools/systems?
>> 
>> 
> 
> -- 
>  Thomas Beale
> Chief Technology Officer 
> +44 7792 403 613   Specification Program, openEHR 
> Honorary Research Fellow, UCL 
> Chartered IT Professional Fellow, BCS 
> Health IT blog   
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at l

CIMI archetype examples using latest openEHR AOM & ADL

[Gerard Freriks]

Ian,

It is fore most a matter of principle.
The question to answer is where are the boundary lines between the different 
layers of the Semantic Stack.
Feel free to blur this anyway you like.

I?m a firm believer that we must prevent problems in the future.

The RM must be stable and must NOT contain any semantic notions.
It must deal with lego-ethical things of storing, retrieving, exchange, etc.

All the health specific semantics have to be dealt with in the archetype layer.
And the set of standardised super-archetypes we use to specialise all other 
from.

The whole business of taking care of the full semantics is to fluid at this 
point in time to be frozen in the RM.

Gerard


Gerard Freriks
+31 620347088
gfrer at luna.nl

On 18 feb. 2014, at 13:11, Ian McNicoll  wrote:

> Hi Gerard,
> 
> Good question. The value is not in the classification but in the
> attributes provided by the class. These save me some work as a
> modeller, should help the developer optimise some system aspects
> optimally (e.g by knowing that every ACTION archetype inherits a time
> and status that can be optimised for querying).
> 
> The first thing to say is that I do not see a particularly clear
> distinction between 'classes' modelled in a Reference model and
> 'top-level' i.e rigid patterns modelled in archetypes. In both cases
> you are providing modellers with some fixed attributes which are
> inherited by child archetypes.
> 
> I am going to use Contsys as an example since this is alternative
> example of where the modellers have introduced specific
> classes/top-level patterns to reduce variability and enhance
> computability.
> 
> IMO it does not really practically matter whether the Contsys
> 'Assessed Condition' is modelled in UML as part of the RM or provided
> as a 'reference archetype' sitting on top of a leaner RM. In both
> cases, if I want to adhere to the ContSys model, I have to inherit
> from 'Assessed Condition'. That puts severe constraints on the way
> that 'Assessed Condition' develops over time. It must remain very
> stable and carefully managed whether an RM construct or a top-level
> archetype.
> 
> So whilst the full-blown generic ENTRY has value, both openEHR and
> Contsys do offer semi-rigid top-level patterns either via RM or
> 'reference archetypes'. In fact 'onotologically' there is a pretty
> close match between the ContSys 'Entry' models and openEHR Entry
> sub-classes
> 
> AssessedCondition = EVALUATION
> Observed/PerceivedCondition = OBSERVATION
> Activity = ACTION
> 
> which is unsurprising since both work from the same 'clinical process model'.
> 
> If we accept that there is some utility in establishing these
> 'top-level patterns', we are inevitably going to run into use-cases
> where it is unclear if an ENTRY is an Observation or Evaluation but
> equally where it is unclear if a Condition is Assessed or Observed
> (smoking or housing summary being a prime example), or a least where
> there is variable interpretation.
> 
> In most case this mixed or muddled classification is not at all
> important for querying purposes. I am not aware of any situations
> where I want to query for Observations. I want to query for 'Smoking
> Summary'., If I happened to model it as an Observation I would get the
> 'observation time' as part of the RM (or top-levle archetype). If I
> modelled it as an Evaluation, I would have to create a date
> recorded/verified' node explicitly in the archetype.
> 
> So t value of the Classes/top-level archetypes are in the attributes
> that child archetypes can inherit, saving modelling effort and
> applying some consistency which can be exploited by developers, but
> there is little value in the classification per-se, other than as a
> guide. We do not query on archetype ENTRY sub-classes.
> 
> 
> Ian
> 
> 
> 
> 
> 
> 
> On 17 February 2014 23:50, Gerard Freriks  wrote:
>> Ian,
>> 
>> Can you answer the question:
>> When 'formal classifications' are unimportant, what is the use of such
>> classifications?
>> 
>> we get caught up on the
>> philosophy and do not focus on the utility
>> 
>> 
>> Caring for the correct meaning is at the same time caring for utility.
>> It is not a philosophical issue.
>> Although some philosophical notions,
>> and linguistic ones
>> are helpful.
>> 
>> Practicalities, translated as 'corners quickly cut', 'quick fixes',
>> look nice in the short run.
>> But how about the long(er) run?
>> 
>> Gerard Freriks
>> +31 620347088
>> g

CIMI archetype examples using latest openEHR AOM & ADL

[Gerard Freriks]

Ian,

Can you answer the question:
When 'formal classifications' are unimportant, what is the use of such 
classifications?

> we get caught up on the
> philosophy and do not focus on the utility


Caring for the correct meaning is at the same time caring for utility.
It is not a philosophical issue.
Although some philosophical notions,
and linguistic ones
are helpful.

Practicalities, translated as ?corners quickly cut', ?quick fixes', 
look nice in the short run.
But how about the long(er) run?

Gerard Freriks
+31 620347088
gfrer at luna.nl

On 17 feb. 2014, at 23:17, Ian McNicoll  wrote:

> Hi Bert,
> 
> I think the problem here is that many people get hung up on the idea
> of the ENTRY classes being a formal classification upon which some
> sort of abstract computing will take place e.g. query for all
> OBSERVATIONS but not EVALUATIONS. i.e. we get caught up on the
> philosophy and do not focus on the utility. In other words if I
> weirdly decide to make problem/diagnosis an ADMIN_ENTRY nothing will
> be lost computationally.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140218/92057a3b/attachment.html>

CIMI archetype examples using latest openEHR AOM & ADL

[Gerard Freriks]

Thomas,

That is fully correct.
Even a ?one? and ?zero? have a well defined meaning, as do their associated 
voltage levels in the CPU.

In our domain of eHealth it must be clear that when we speak about ?Semantic' 
we mean health related semantics, the clinical aspects.
I am a firm believer in a separation of concerns between the various layers in 
the semantic stack.
The RM must address the legal and ethical aspects of document structure of any 
thing.
Archetypes/Templates deal with the eHealth/Clinical semantics inside these 
structures.

There is nothing misleading.
It is wrong to mix general legal ethical aspects, document structure aspects, 
with specific health specific semantic aspects.
It is a wrong idea to mix these aspects.
The domain specific but invariant aspects must be dealt with in standardised 
patterns we use to construct (clinical, administrative, management, re-use) 
archetypes and templates.
And some parts of the semantics, as you advocate, in the RM and others in 
archetype patterns is wrong.
That is my opinion.


Gerard Freriks
+31 620347088
gfrer at luna.nl

On 16 feb. 2014, at 14:18, Thomas Beale  
wrote:

> 
> this is a common but misleading idea! There are semantics everywhere. Even 
> the type 'Integer' has some semantics. The question is what semantics should 
> be in the RM versus what should not be. My view is that 'domain-invariant 
> semantics' should be included (for whatever you say your domain is, e.g. EHR, 
> health data etc), and that variable semantics should go into archetypes. The 
> trick is to work out where that boundary actually is.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140216/3f886873/attachment-0001.html>

Intra-archetype semantic relationships

[Gerard Freriks]

Do I understand that one of the proposals is to have an external resource 
define what the archetype is?

For SIAMM we decided that all the data that describe all relevant semantical 
aspects of the archetype must be defined inside that archetype as part of the 
archetype pattern.
External services can use that data to manage the archetype libraries.
That relevant data is to be found in the MetaDataArtefact branch of the pattern 
and in the Name and NameType parts.

- MetaDataArtefact describes general aspects of the artefact.
 (what class of the RM, applicable ContSysTerm, how the artefact is used in the 
EHR-system (e.g. presentation, exchange, etc.),
  what aspect of healthcare provision the artefact is used for (diagnostics, 
Treatment, Administrative, Management, Re-Use, etc.)
- Name and NameType give the specific name related aspects of that artefact. 
(e.g. NameType:LabFinding, Name=BloodSerumGlucose)

The Slot Mechanism must rely on this data inside  the archetypes for the 
(de-)selection of candidate slot fillers.

Gerard Freriks
+31 620347088
gfrer at luna.nl

On 15 jan. 2014, at 10:09, Diego Bosc?  wrote:

> I agree that sometimes regular expressions can be tricky, and surely they 
> don't look pretty on its current form. However, but they have an advantage: 
> They are formal and easily evaluated in any language. The problem I see with 
> this approach is that you will need a single ontology (or access to it) to be 
> able to assure that the meaning is the same for everyone. Also you will have 
> to forbid more radical changes that are being made on the archetypes 
> (changing its root entity, for example).
> 
> Also, if this approach is taken, precise rules and clarifications are needed. 
> e.g. in the last example, are 'massage' children allowed? (in other words, 
> does EXCEPT refer to the children too or not?). Are there some kind of 
> precedence rules implied? These kinds of things should be formally defined in 
> any case.
> 
> 
> 2014/1/14 Thomas Beale 
> On 14/01/2014 11:07, Diego Bosc? wrote:
> I like the idea, we were already exploring something similar to this for 
> intra-archetype semantic relationships.
> 
> 
> Since Diego brought up the topic
> 
> one of the final things needed in ADL/AOM 1.5 is a better kind of slot, which 
> works off an ontology of archetypes. The question is: is the ontology 
> hierarchy defined by their specialisation relationships (and going up into 
> the categories Observation, Evaluation etc) or by some independent ontology? 
> The former would be automatically extractable from the specialisation 
> relationships of a population of archetypes, but the latter is more likely to 
> work as needed. Anyway, assuming that the ontology can be established (e.g. 
> in CKM or somewhere), new slots would look something like:
> 
> items matches {
> 
> allow_archetype CLUSTER[id24] matches {< device_description OR << 
> manual_procedure}
> }
> 
> Where 'device' means CLUSTER archetypes classified under a device_description 
> node in the ontology. The '<' means any child (but not this concept), '<<' 
> means this concept or any child. The value of this approach is that you may 
> define your slot and publish your archetype, then some time later, you 
> realise you need to allow a new archetype to be a slot filler. Assuming that 
> the new archetype can be reasonably classified as a 'device' or 'manual 
> procedure' then you do this in the ontology, and your slot definition now 
> evaluates to pick up your new archetype - no changes needed to either 
> archetype.
> 
> More complex constraints could be defined:
> 
> items matches {
> 
> allow_archetype CLUSTER[id24] matches {< device_description OR << 
> manual_procedure EXCEPT massage }
> }
> 
> These kinds of expressions start to look like ref-set definitions, where the 
> ref-set are being defined on the archetype ontology rather than some external 
> terminology like SNOMED. If the archetype ontology were defined in a SNOMED 
> extension or similar, the same technical tools could be used to evaluate 
> slots.
> 
> - thomas
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20140115/0c955916/attachment-0001.html>

Rich text format in DV_TEXT

[Gerard Freriks]

So do I

GF

Gerard Freriks
+31 620347088
gfrer at luna.nl

On 24 sep. 2013, at 09:42, Ian McNicoll  
wrote:

> Hi Bert,
> 
> This is perfectly legal ADL created with the Ocean AE - it allows for
> a single value with a 'choice' of datatype. We use this pattern fairly
> frequently.
> 
> Ian

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130924/ba42f92a/attachment-0001.html>

openEHR-technical Digest, Vol 18, Issue 50

[Gerard Freriks]

William,

You have produced a lot of archetypes based on clinical input, that in the end 
were, well considered, well discussed, co-ordinated, agreed, ad-hoc, 
collections of what clinicians expect in a local context, to see on a screen to 
look at, and be used for data capture.
It is a lot of experiences.

Questions:
Have you produced a lot of Template stuff?
Or,
have you produced semantic interoperability artefacts?


Gerard Freriks
+31 620347088
gfrer at luna.nl

On 30 aug. 2013, at 18:42, William Goossen  wrote:

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



-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130831/9150ddb4/attachment-0002.html>
-- next part --
A non-text attachment was scrubbed...
Name: pastedGraphic.pdf
Type: application/pdf
Size: 73662 bytes
Desc: not available
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130831/9150ddb4/attachment-0001.pdf>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130831/9150ddb4/attachment-0003.html>

openEHR-technical Digest, Vol 18, Issue 38

[Gerard Freriks]

Daniel,

Closed and Open world assumptions are used the world of:
- Formal logic
- Knowledge representation

This notion of Open and Closed world assumptions occured to.
Let me explain.
I happen to see a parallel/overlap between: systems that serve a well defined 
(Closed) community with implicit and explicit agreements and systems to deal 
potentially with not yet defined things in an not defined (Open) community.
In a system according to the Closed World Assumption all data fields are 
explicitly and implicitly agreed upon. Nothing that is not defined can not be 
processed, just like Relational Data bases and messages.
In a system according to the Open world assumption the semantics of a data 
field are fully defined semantically by archetypes and reference terminologies. 
There is (almost) no implicit meta-data. Ontological reasoners can fully 
exploit the data. These are the systems we want but do not have on the market.

Do you have any suggestion for alternative terms?

Gerard



Gerard Freriks
+31 620347088
gfrer at luna.nl

On 29 aug. 2013, at 11:12, Daniel Karlsson  wrote:

> Gerard, Everyone,
> 
> could you please *NOT* reuse existing terms like "open world" and
> "closed world" with an already agreed specific meaning in a well-defined
> context for your own purposes!
> 
> On the topic of descriptive vs. prescriptive I believe that that is an
> additional dimension in this discussion. I still want to have an answer
> to the question of what to do with archetype nodes for which there are
> no existing terminology correspondence. Should we ban those archetype
> nodes or should we (over)inflate terminologies with imprecise content or
> should we just accept that archetypes and terminology are different
> artefact beasts with different properties and that we have to thread
> carefully balancing terminology binding possibilities and specific use
> case requirements?


I have questions:
What is the purpose of a Reference terminology when it is missing essential and 
relevant lemma's?
Perhaps we need several Reference terminologies?
Then the next question is how do we delineate more than one Reference 
Terminology?

One thing I know:
We need an agreed list of words we use, reflecting concepts we need, in the 
context of health data inside systems and between systems.
We need a Reference Terminology as a kind of dictionary.
How many dictionaries do we need?
One per domain such as: anatomy, demographics, medicinal product, health and 
care services (interventions, lab-tests, etc.), structure of documents, units 
of measurement, family relations, kinds of media formats, etc., etc.



> 
> /Daniel

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130829/61a3b36d/attachment-0001.html>

openEHR-technical Digest, Vol 18, Issue 38

[Gerard Freriks]

yes, I agree.

And it is the same as communication in a 'closed world' or 'open world' 
situation.


Gerard Freriks
+31 620347088
gfrer at luna.nl

On 29 aug. 2013, at 09:50, gjb  wrote:

> Re: Ontology & archetype codes
> 
> aren't we, here, in the realms of Descriptive v. Prescriptive Grammar?
> 
> http://grammar.about.com/od/basicsentencegrammar/f/descpresgrammar.htm
> 
> *Descriptive* obliges you to change whenever the language seems to.
> 
> *Prescriptive* obliges you to try to hold the language static.
> 
> The hard bit is gauging the utility of responding to any given change.
> 
> 
> Gavin Brelstaff
> CRS4 in
> Sardinia
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at lists.openehr.org
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130829/b67e19cb/attachment.html>

Polishing node identifier (at-codes) use cases.

[Gerard Freriks]

Why bring in religion?

I want to understand and ask questions.
And in the meantime I have an opinion based on my 'GBV'. (see below)

> Can you please give reasons for your statements that archetype nodes must be 
> unique concepts and must be uniquely identified? 
> 

Reasons for my statement?
- Each node in an archetype has a meaning
- Without an implicit or explicit meaning the archetype node indicates chaos, 
meaninglessness, nothingness.
- Meaning is attached to the given name of the node or code attached to that 
node
- In the case of specialisations of archetypes several things can happen, one 
of those is renaming the node, changing the meaning
- This changing the name and meaning of the archetype node needs to be 
reflected in a new unique code

So far I have not explained the scope, the jurisdiction, the namespace, of the 
unique codes I'm alluding to.
At the minimum it must be uniquely defined inside the archetype, and in the 
case of a code from an external coding system, it must be unique in that 
namespace.

> I have never been given a scientific reason why every node in an archetype 
> should be uniquely coded or have unique meaning outside the archetype itself. 
> I have never found a use case that makes this necessary but would be 
> interested if anyone can show me one.
> 


It all depends on scope of the archetype. Is it used in an 'open world' or 
'closed world' situation?
When used in a 'closed system' ( two or more actors that have an agreement of 
that what is exchanged, IHE with one profile) there is almost no need for 
external codes attached to archetypes. The explicit or implicit agreement is 
sufficient. Whatever the name in the archetype node, when the agreement says, 
the node name means 'Black', but we take to mean 'White' then there is no 
single problem.
In 'Closed world systems' the highest level of semantic interoperability is 
Level2a/2b at the best. It is the world of messaging with ad-hoc agreements, as 
we know it.

When the archetype is used in an 'open world' system, then we need to be very 
precise and explicit. Any party that interprets the data using the archetype as 
source, where it must find the meaning, needs to be informed fully. No single 
human intervention, human interpretation, must be needed to process fully and 
safely the data exchanged.
Local agreements between actors how to interpret the archetype node name do not 
exist, the archetype itself is the full agreement.
In 'Open world' systems the highest level of semantic interoperability is level 
3.
In this 'open world' situation there are other rules than in the 'closed world' 
situation.


Finally.
Do not create a  dichotomic world where things are either science or religion.
There are many shades.
And in order to surprise you:
Do not underestimate something that I call in Dutch: 'het gezonde boeren 
verstand'. (GBV)
Translated: the common sense of the farmer.
Many obvious things that happen in life, happen because they happen.
I do not have to prove, that water flows, that fire burns, that winds exits, 
for you and me to accept this is true,
with or without a science, with or without any belief system, with or without 
any dogma.

I try to base my own opinions on my 'GBV'.

Gerard Freriks
+31 620347088
gfrer at luna.nl

On 29 aug. 2013, at 00:13, Hugh Leslie  
wrote:

> Hi Gerard, 
> 
> This is science, not religion. Can you please give reasons for your 
> statements that archetype nodes must be unique concepts and must be uniquely 
> identified? 
> 
> In openEHR and 13606, the archetype is the unique concept which means that 
> nodes quite rightly can have unique meaning in the context of the archetype. 
> This is like human language where the same word can have different meanings 
> depending on the context used.
> 
> I have never been given a scientific reason why every node in an archetype 
> should be uniquely coded or have unique meaning outside the archetype itself. 
> I have never found a use case that makes this necessary but would be 
> interested if anyone can show me one. 
> 
> Regards Hugh
> 
> 

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130829/f83f1222/attachment.html>

Polishing node identifier (at-codes) use cases.

[Gerard Freriks]

David,

Can I summarise it for my understanding as:
- AT codes are pointers to an 'ontology'.
- AT codes can be considered symbols that represent a particular concept
- The 'ontology' provides a name that will be used to display the name of a 
node (concept) in an archetype.
- When a node is specialised the node name used will indicate a new concept 
(its meaning has changed)
- When the archetype is specialised ideally the new concept in the 
specialisation is a subordinate concept.
- When a Node is specialised the standard does not prescribe that the new 
concept is a sub-set of the previous one.
- The question is: is each Node (and the concept it represents) unique or not.
- The question is: is it obligatory that each node in the archetype carries a 
unique code  of the form AT .

My answers to both questions are:
- Each archetype node is  a unique concept that must have attached to it a 
unique identifier.
- Archetype editors must support this.

And I would like to add:
- When specialising each specialised concept must be a subset of its previous 
one.


Gerard Freriks
+31 620347088
gfrer at luna.nl

On 28 aug. 2013, at 09:13, David Moner  wrote:

> 
> I'll try to summarize the origin of the different views we have regarding 
> this topic and maybe this can be also useful to see why this is not just a 
> configuration problem of the tools.
> 
> We can find the explanation of node identifiers in two places (I use the 
> latest drafts, I think):
> - In AOM 1.5 specifications, page 47: "Semantic identifier of this node, used 
> to distinguish sibling nodes of the same type. [Previously called ?meaning?]. 
> Each node_id must be defined in the archetype ontology as a term code."
> - In ADL 1.5 specifications, page 26: "In cADL, an entity in brackets of the 
> form [at] following a type name is used to identify an object node, i.e. 
> a node constraint delimiting a set of instances of the type as defined by the 
> reference model." and  "A Node identifier is required for any object node 
> that is intended to be addressable elsewhere in the same archetype, in a 
> specialised child archetype, or in the runtime data and which would otherwise 
> be ambiguous due to sibling object nodes"
> 
> The definition in AOM is the one followed by the openEHR editor, i.e. a node 
> identifier or at code is just a pointer to the ontology section and a 
> mechanism to distinguish sibling nodes. Thus, wherever it is not needed, the 
> tool does not introduce that code in order not to dirty the ontology section.
> 
> The  first part of the definition in ADL is the one followed in LinkEHR and, 
> in our opinion, more correct formally. When you introduce an archetype 
> constraint for a C_OBJECT you are in fact creating a definition of a type (a 
> sub-type of the more generic type defined by the reference model class) that 
> will be used to create a subset of instances. We have to distinguish this 
> sub-type from the RM type, and since the class name cannot be changed, the 
> only solution is to use the at as type identifier. In other words, our 
> interpretation is that at codes are unique identifiers of each type 
> defined in the archetype, that may be also used to link to the ontology 
> section, but that is the optional part. In fact, the only exception to this 
> would be when you create constraints using a path, because then you are just 
> navigating through the RM but do not change the meaning of the intermediate 
> classes.
> 
> The logic of the tools and the validation checks of archetypes are built 
> based on those interpretations. I agree with Bert in one thing: tools 
> shouldn't change things without notifications, but in this case we face a 
> methodological difference, not just a configuration one, and that's why it is 
> not easy to be solved.
> 
> David
> 

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130828/1595399d/attachment.html>

Recording absence of (clinical) information

[Gerard Freriks]

Dear Koray,

According to SIAMM:

Any thing can be negated (or better it is declared that something is absent.
Since each ENTRY archetype is a named process that is: ordered, executed, 
assessed or summarised after termination, we can describe:
- that there is no order, no execution, no assessment or perception of the 
summary after termination of a specific named Action, Protocol, Clinical 
Pathway.
- in addition it is possible that as the result of a query specific data is not 
found. (e.g. No recording of any Blood Glucose, no recording of Blood Glucose: 
> 12 mMol/L)

This Presence/Absence indicator is NOT a boolean data type but a fixed text: 
Present/Absent
 
In addition, after long debates, it had been decided in the CEN/ISO Task Groups 
that in the RM we have one flag that indicates that something is 'fishy'.
It is the 'Attention' attribute in the ENTRY class.

Gerard Freriks
+31 620347088
gfrer at luna.nl

On 15 jul. 2013, at 09:41, Thomas Beale  
wrote:

>> Hi everyone,
> Hi koray,
> how do you want to do this? We decided against absence / exclusion in th RM a 
> long time ago, 
> because it is not a simple negation in general, but a complex (i.e. 
> archetyped) statement.
> 
> -thomas

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130715/f6dfd00d/attachment-0001.html>

TDS (and TDD) implementations?

[Gerard Freriks]

The best example is:
One ENTRY archetype node that can have one ore more Clusters added to it - when 
allowed -of course-via Archetype slots at run- or design time.



Gerard Freriks
+31 620347088
gfrer at luna.nl

On 14 jun. 2013, at 13:01, Daniel Karlsson  wrote:

>> Using the 13606 AOM based tools it must be possible to track the whole
>> provenance of any archetype/template.
>> (There is a problem known for Archetype Slots and keeping track of the
>> original choices that were expressed.)
>> Although the template might be a sub-set in places and a super set in
>> other places,
> as I said I don't think this is the case, but if there are issues these
> should be discussed and straightened out. Do you have specific examples
> or template functions where templates loosen constraints?

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/e9787307/attachment.html>

TDS (and TDD) implementations?

[Gerard Freriks]

One simple example:
I can have an archetype slot that is filled at run-time as allowed by a regular 
expression or a hand entered list of possible archetypes that can fill that 
slot.
But there are more examples.

Gerard Freriks
+31 620347088
gfrer at luna.nl

On 14 jun. 2013, at 13:01, Daniel Karlsson  wrote:

>> 
>> In a parent one node can allow zero to many siblings
>> In a specialisation we can constrain it to any within the limits as
>> specified by the parent.
>> When allowed we can remove branches with zero-to-zero constraints and
>> not use them at all.
>> We can insert (when allowed) in places additional nodes (new banches)
>> that were not in the parent.
> Can you provide an example because I thought the latter was not allowed
> (depending on what a branch is).

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/8c9d4f5b/attachment.html>

TDS (and TDD) implementations?

[Gerard Freriks]

Compact serialization?

When nodes in the archetype while they are developed and can change in the 
'template' level or even during run-time,
there never will be a simple serialization to an XML/XDS format. To much is 
volatile.


When you say ' more compact serialization formats'
do you mean shorter XML payload that go ver the wire?

Observe that when parties decide to be semantically interoperable this means 
that every data point and all its context needs to be sent over the wire.
Full semantic interoperability demands more resources than just updating fields 
in a database.



Gerard Freriks
+31 620347088
gfrer at luna.nl

On 14 jun. 2013, at 13:01, Daniel Karlsson  wrote:

>> 
>> When specializing an archetype the name (and meaning) changes.
>> When originally the Name node is ENTRY it can be changed in
>> specialization to ENTRY:Observation
>> Or into ENTRY:Observation:ClinicalFinding
>> Or into ENTRY:Observation:ClinicalFinding:BodyTemperature
> That's fine, but serializing is not specializing. Templates also allow
> specializing (that is in a way what templates do) as does archetypes so
> there's an overlap. But that's a separate (and important) issue. I was
> asking about the possibility of having more compact serialization
> formats.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/a9baa6e5/attachment.html>

TDS (and TDD) implementations?

[Gerard Freriks]

Dear Thomas,

Why do we (CIMI) need a TDD?
Isn't a TDD a transformation that is used during the implementation of a 
Template.

We in CIMI -I think, we agreed- is about Clinical Information Models. CIMS.
CIMS that can be transformed to openEHR expressions, 13606 expressions, CDA, 
all expressed as constraints on there respective Reference Models.

These CIM's, once transformed, are used in Templates that will be used locally.
And only then at implementation time implementers want something in XML. And 
that is the TDD.

I think it is completely out of scope for CIMI to talk about Archetypes 
expressed as constraints on their Reference Model
and it is even more out of scope to deal with Templates
and it is absolutely out of scope to deal with implementation issues such as 
XML representations of an implementable Template designed for local use.



Gerard Freriks
+31 620347088
gfrer at luna.nl

On 14 jun. 2013, at 12:31, Thomas Beale  
wrote:

> On 14/06/2013 08:56, Gerard Freriks wrote:
>> Hi,
>> 
>> While we are at it.
>> 
>> -1-
>> Why do we need a TDD?
>> Isn't a Template just a Composition archetype with Sections archetypes and 
>> ENTRY archetypes and Cluster archetypes and Element archetypes plus data 
>> types.
> 
> that's what a template is; but a TDD (Template Data Document) is something 
> different. It's not an XML instance of the canonical (i.e. RM) information 
> model XSD, it's an instance of a transform of that, called a TDS (Template 
> Data Schema). 
> 
> A TDS is something like a 'green CDA' schema but generated from the AOM 
> template structure. The tag set is a mixture of standard RM attribute names 
> (like 'start_time', 'events', etc), and for the data attributes, names 
> derived from the archetype node ids, i.e. things like 'serum_sodium', or 
> 'total_cholesterol'. The result is an XSD whose tagset consists of basic 
> openEHR context attributes (always the same) and template specific data 
> attribute names.
> 
> There is therefore one TDS per template - each TDS is its own schema. 
> 
> A TDD is an XML document instance of a TDS.
> 
>> In addition as many possible degrees of freedom need to be constrained so as 
>> to reflect the agreement between the two exchanging actors.
>> In all aspects they rare nothing but an archetype in my part of the world.
>> The peculiar thing about templates is that they are for prime time actual 
>> use/deployment.
> 
> that's true, but not only that - you need templates to define a data set of 
> any kind. Except in some coincidental cases (like some labs), archetypes 
> don't on their own define useful or complete data-sets. So if a government 
> wants to mandate a discharge summary or e-referral document, they need to 
> define a template to do that, made up of specifically chosen attributes from 
> a set of chosen archetypes.

Data sets are ad-hoc collections of individual data points.
They are out of scope for CIMI, I think.
We need to bother ourselves with 'How do we model the individual data points 
and all their context?



> 
>> 
>> -2-
>> Transformations:
>> The Template (archetype) has node names changed in places (and therefor 
>> their meaning).
> 
> At a technical level, the 'meaning' of each node can't be changed from the 
> archetype - and that is the meaning that is computed with. I agree that in 
> some cases, the clinical meaning may be different, but it should always be 
> refined, not arbitrarily different. ADL/AOM 1.5 addresses this properly and 
> makes all template refinements regular and computable.

One can compute as much as we like.
When we specialize we change meaning (Names of the rate fact and the nodes, 
Constraints, Codes attached)
The at-code can be the same, and that is what is used to compute with.

Even a 'refined' node name means changing the meaning into a 'refined meaning'.




> 
>> They are more complex in places (because new branches) have been added, less 
>> complex in places (because branches are not used), more constrained in 
>> places than the pure parent archetype.
> 
> Currently, no new data at all can be added in an opernEHR template, and no 
> new branches. The only 'new' thing that can be added is clones of existing 
> archetype nodes to account for specific multiplicities required by that data 
> set.

I equate archetypes with templates.
Only Templates are defined to be implemented in a local temporal context and 
will contain: EHR-Extract, one or more Composition, Entry and Elements as 
minimum component.

Archetypes (and CIMI is talking archetypes) can be changed in any that I 
indicated.
Even at run-time arche

TDS (and TDD) implementations?

[Gerard Freriks]

See below
Gerard Freriks
+31 620347088
gfrer at luna.nl

On 14 jun. 2013, at 11:09, Daniel Karlsson  wrote:

> On Fri, 2013-06-14 at 09:56 +0200, Gerard Freriks wrote:
>> Hi,
>> 
>> 
>> While we are at it.
>> 
>> 
>> -1-
>> Why do we need a TDD?
>> Isn't a Template just a Composition archetype with Sections archetypes
>> and ENTRY archetypes and Cluster archetypes and Element archetypes
>> plus data types.
> With ADL 1.5, yes I believe.

We, EN13606 Association, use the ADL1.4 spec in our tool: LinkEHR.
This is sufficient for our and CIMI purposes, we believe.


> 
>> In addition as many possible degrees of freedom need to be constrained
>> so as to reflect the agreement between the two exchanging actors.
>> In all aspects they rare nothing but an archetype in my part of the
>> world.
> Ok
> 
>> The peculiar thing about templates is that they are for prime time
>> actual use/deployment.
> What's peculiar about that?

'Normal' archetypes can be produced just to produce other archetypes at design 
time.

Templates are for specific use in a specific context and moment in time when 
actors define a screen or the content of an exchange.
Of course Templates can be designed as templates to be used in local contexts.

Archetypes can not be used without the Composition because a lot of the audit 
info and other info needed for versioning is defined at the Composition level.
The meta-data about the pay load is defined in the EHR-Extract.
Templates are mostly EHR-EXtracts with Compositions inside.

> 
>> 
>> -2-
>> Transformations:
>> The Template (archetype) has node names changed in places (and
>> therefor their meaning).
> No, these are (should be) just two alternative serializations of the
> same meaning. However, what constitutes the meaning of an archetype is
> not a trivial question.

When specializing an archetype the name (and meaning) changes.
When originally the Name node is ENTRY it can be changed in specialization to 
ENTRY:Observation
Or into ENTRY:Observation:ClinicalFinding
Or into ENTRY:Observation:ClinicalFinding:BodyTemperature

The names are different and therefore their meanings.
Although all names are related to each other.



>> They are more complex in places (because new branches) have been
>> added, less complex in places (because branches are not used), more
>> constrained in places than the pure parent archetype.
> Here I must confess I don't understand your use of the word "complex".
> E.g. if there in an openEHR model is two specific named events in an
> observation which are expanded in the TDD (isn't it??) does this
> increase or decrease complexity?


In a parent one node can allow zero to many siblings
In a specialisation we can constrain it to any within the limits as specified 
by the parent.
When allowed we can remove branches with zero-to-zero constraints and not use 
them at all.
We can insert (when allowed) in places additional nodes (new banches) that were 
not in the parent.


>> 
>> 
>> To write generic transformations is not trivial, I expect.
>> If possible at all.
> I do not agree. I believe this is what every implementer necessarily has
> to do, to provide a two-way transformation between a canonical form and
> any serialization and/or persistence form with a different set of
> requirements (query performance, OLTP vs. OLAP, space requirements,
> legacy systems integration, etc. etc. etc.). Not trivial but done on a
> regular basis.
> 

Using the 13606 AOM based tools it must be possible to track the whole 
provenance of any archetype/template.
(There is a problem known for Archetype Slots and keeping track of the original 
choices that were expressed.)
Although the template might be a sub-set in places and a super set in other 
places, all must conform to the Reference Model and all parent archetypes that 
were used in the chain of specializations.

Without the complete set of artifacts the transformation will be NOT possible,
Tracking all these changes that were made to the parent archetype


> 
> Cheers,
> Daniel
> 
>> Gerard Freriks
>> +31 620347088
>> gfrer at luna.nl
>> 
>> On 14 jun. 2013, at 09:41, Daniel Karlsson 
>> wrote:
>> 
>>> Hi Ian,
>>> 
>>> On Thu, 2013-05-30 at 10:34 +0100, Ian McNicoll wrote:
>>>> Hi Erik,
>>>> 
>>>> 
>>>> The Ocean TDD->canonical transform is available at
>>>> 
>>>> 
>>>> http://openehr.codeplex.com/SourceControl/latest#176376
>>>> 
>>>> 
>>>> 
>>>> look for TDD_to_openEHR.xsl
>>>> 
>>>> 
>>>> As far as I 

TDS (and TDD) implementations?

[Gerard Freriks]

Hi,

While we are at it.

-1-
Why do we need a TDD?
Isn't a Template just a Composition archetype with Sections archetypes and 
ENTRY archetypes and Cluster archetypes and Element archetypes plus data types.
In addition as many possible degrees of freedom need to be constrained so as to 
reflect the agreement between the two exchanging actors.
In all aspects they rare nothing but an archetype in my part of the world.
The peculiar thing about templates is that they are for prime time actual 
use/deployment.

-2-
Transformations:
The Template (archetype) has node names changed in places (and therefor their 
meaning).
They are more complex in places (because new branches) have been added, less 
complex in places (because branches are not used), more constrained in places 
than the pure parent archetype.

To write generic transformations is not trivial, I expect.
If possible at all.

Gerard Freriks
+31 620347088
gfrer at luna.nl

On 14 jun. 2013, at 09:41, Daniel Karlsson  wrote:

> Hi Ian,
> 
> On Thu, 2013-05-30 at 10:34 +0100, Ian McNicoll wrote:
>> Hi Erik,
>> 
>> 
>> The Ocean TDD->canonical transform is available at
>> 
>> 
>> http://openehr.codeplex.com/SourceControl/latest#176376
>> 
>> 
>> 
>> look for TDD_to_openEHR.xsl
>> 
>> 
>> As far as I know a generic reverse transform is not possible.
> 
> How could that be? Is there something in the TDD format that is not in
> the RM format? The intuition tells me that it should be easier going
> from the rich RM format to the TDD format than in the opposite
> direction. What are the specific issues that make a reverse
> transformation problematic? Could anything be changed to make the
> transformation possible?

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20130614/ddeb7b6f/attachment.html>

lessons from Intermountain Health, and starting work on openEHR 2.x

[Gerard Freriks]

See below.
On 4 Oct 2012, at 18:07, Thomas Beale wrote:

> On 03/10/2012 23:26, Gerard Freriks wrote:
>>> I just care about getting one model 
>> 
>> In the case of 13606 one good model that describes a generic interface for 
>> EHR communication, also, for communication with other proprietary EHR 
>> solutions.
>> In the case of openEHR one good model that describes one particular 
>> implementation of an EHR-system.
>> 
>> This difference is something the EN1366 Association cares about.
>> 
> 
> well except that the above is a misunderstanding of openEHR, so if the 13606 
> association works on that basis they will miss the opportunity to get 
> harmonisation.

Whatever openEHR aspires to be, it is clear that the scope of 13606 is EHR 
Communication in general.
It has been made clear that, in the renewal process of the 13606 EHR 
Communication standard, EHR-system implementation specifics are out of bounds.
The scope of 13606 will not be extended to match the scope of openEHR.



> openEHR is a model for an open EHR (it's in the name ;-), and includes three 
> kinds of semantics:
> core semantics that apply for any use of health information - messages, EHR 
> systems, documents etc
> semantics that describe accessing EHR information in repositories - any 
> repository
Accessing data in repositories is definitely out of scope for 13606 in this 
round of updating.
> semantics that describe EHR information in an Extract from one system to 
> another - any kind of system
If openEHR is serious about its scope, to be a general receiver of health data, 
then its Reference Model must become much more generic than it is now,
The 13606 Reference Model is very generic just to serve this important 
requirement that it must be able to deal with all systems. 


> These are used to specify the interfaces of EHR systems, EHR gateways (that 
> sit next to existing EMR systems), and EHR Extracts. The openEHR architecture 
> describes the externally shareable information semantics, not the internal 
> implementation. The implementations are the business of vendors, and are all 
> different. In other words, openEHR is an interoperability description of the 
> system - how the information and services look from the outside.
> 
> Insofar as 13606 has been used (uptake by industry vendors appears very low 
> as far as we can tell),

Hm?


> it has been used to build either EHR systems or gateways, rarely messages, 
> which is what it designed for. This seems a fair indication that what the 
> sector wants is a specification for the interoperability interface of the 
> systems and gateways required to even connect a healthcare enterprise to the 
> outside world - and additionally, a specification for making EHR Extracts in 
> these systems.

13606 based interfacing systems have proven to be capable of extracting data 
from any feeder system, transform it into the 13606 format, and into any other 
structured format.
And do this in matter of days.
We do not need openEHR to do that.


> 
> A specification only for EHR Extracts is not that useful, what the sector 
> clearly wants are specifications of the interoperability interface of 
> systems, as well as messages they might create. That's the opportunity here 
> for us working on these standards.

All this is within the scope of 13606.
It is misleading to suggest that the scope of 13606 is just messaging. EHR 
Extracts are about interoperability of data objects in general.


> 
> 13606 needs to be updated a priori, and has lessons from use waiting to be 
> implemented; openEHR has lessons from the last 5 years of use which will lead 
> to changes, so there is scope for change and harmonisation. I think the 
> community here, and also the stakeholders are interested in practical 
> proposals for a new set of standards that actually address needs.

I'm happy to announce that there is a wealth of implementation experience not 
only in the world of openEHR.
There is a wealth of experiences in deploying the 13606 EHR communication 
standard in hospitals, research, regions.
Sometimes in relation with HL7 CDA artefacts, sometimes to create applications 
for data entry, sometime integrated with ontological applications.

In the meantime I sincerely hope that harmonisation is possible without making 
too many unneeded remarks about potential partners.


> 
> - thomas

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121005/65054182/attachment.html>

lessons from Intermountain Health, and starting work on openEHR 2.x

[Gerard Freriks]

Dear Koray,

We both agree that the scopes of CEN/ISO 13606 and openEHR differ, as I wrote.
The scope of 13606 is about EHR communication.
That of openEHR is about the implementation in an EHR system.

At present a standard is missing about defining clinical content.
It would be nice, certainly, when both 13606 and openEHR can share that 
standard for clinical content.
In several places the EN13606 Association, whose scope is wider than the 
European context, is actively working towards that goal.
This single approach for a standard for clinical content is very important when 
we want generic semantic interoperability.
This is the reason why components for a potential standard on archetype 
production are developed inside the Association.
A standard that defines the intersections with: coding systems, ontologies, 
other CEN/ISO standards like System of Concepts for Continuity of Care and the 
Health Information Services Architecture.
All resulting in one basic generic pattern, for all artefacts, that by 
specialisation is able to be used for all kinds of archetypes.
A basis pattern that in more detail allows the definition of more nuances than 
the archetypes we know, so far.
A basic pattern that brings features closer to actual use such as negation, 
semantic ordinals (with inclusion and exclusion criteria), better integration 
with clinical workflow, ontological reasoning over structure and codes, etc.

The EN13606 Association of implementors of the 13606 standard has considerable 
experience in the production of applications based on this standard.
When I look into future needs and developments around the use of coding systems 
and ontologies, I see state of the art developments among the members of the 
Association.

W3C is a good example. indeed.
As far as I know W3C does not prescribes how to implement their standards in 
systems.
This is the responsibility of the industry in all circumstances.


Gerard Freriks
+31 620347088
gfrer at luna.nl




On 4 Oct 2012, at 02:02, Koray Atalag wrote:

> Hi Gerard,
> I think getting the content model is absolutely right ? no one can argue
> But with due respect I disagree with you about the difference. I seriously 
> think standards defining clinical content should converge (not even 
> harmonise).
> I had the privilege of spending some time with Ed Hammond in NZ and was 
> convinced that this is what is needed. Mappings are different and certainly a 
> blackhole.
> That said EN13606 Association?s mission and role is paramount in terms of 
> contextualising ?exchange? within the European context.
>  
> We chose to use openEHR for defining the Interoperability standards in New 
> Zealand as we are very mindful of the fact that this formalism has been 
> defined and carried on for many years by this group; and it IS naturally the 
> leading edge with proven track in implementation (one of which is my own 
> work). I think W3C is a good example of how important it is to have a single 
> approach in contrast to the situation in health IT. These might sound a bit 
> strong but it is what I believe. I acknowledge lack of organisational 
> capacity and skills in past though.
>  
> Cheers,
>  
> -koray
>  

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121004/a784cb63/attachment.html>

lessons from Intermountain Health, and starting work on openEHR 2.x

[Gerard Freriks]

> I just care about getting one model 

In the case of 13606 one good model that describes a generic interface for EHR 
communication, also, for communication with other proprietary EHR solutions.
In the case of openEHR one good model that describes one particular 
implementation of an EHR-system.

This difference is something the EN1366 Association cares about.

Gerard Freriks

EN13606 Association
p/a Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

M:  +31 620347088
E: gerard.freriks at EN13606.org
W:  http:www.en13606.org

On 4 Oct 2012, at 00:02, Thomas Beale wrote:

> On 13/09/2012 10:15, David Moner wrote:
>> Hi,
>> 
>> 2012/9/13 Erik Sundvall 
>> It would be great if e.g most of the future ISO 13606 version could be a 
>> true subset of openEHR instead of the current confusing situation. 
>> 
>> This is something I discussed with Thomas some time ago, it would be one of 
>> the best harmonisation solutions, but probably with a slightly different 
>> interpretation. Since 13606 has more generic classes (eg. the generic ENTRY 
>> can represent all of OBSERVATION, EVALUATION, INSTRUCTION, ACTION), instead 
>> of 13606 being a subset of openEHR I think that openEHR should be a 
>> specialized model of 13606. Obviously this would require a deep analysis and 
>> changes of the models, but that could be the idea.
> 
> I don't care about the linguistics of subset / specialisation etc, I just 
> care about getting one model 
> 
> - thomas




Gerard Freriks
+31 620347088
gfrer at luna.nl




-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20121004/846345bc/attachment.html>

Regarding the role of ITEM_STRUCTURE

[Gerard Freriks]

Yes.

It all is about classifying.
It is all about proper definitions we all share and use.

I believe that when we all interpret the definitions in our own way in our own 
data bases all is working nicely.

The moment we start to exchange this data we will discover that we are not 
interoperable,
The moment we start to re-use data in clinical decision support service we will 
discover that all systems that worked so nicely, have become problems to 
connect.

As EN13606 we work at full semantic interoperability as much as possible.
So we have to define many things, we use to produce archetypes, properly.
Don't we all have an obligation to make semantic interoperability possible?


Gerard Freriks
+31 620347088
gfrer at luna.nl




On 22 Jun 2012, at 02:45, Jussara wrote:

> Think the background of our discussions is about CLASSfying.
> 
> Sent from my iPad

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120622/548ed0bb/attachment.html>

Regarding the role of ITEM_STRUCTURE

[Gerard Freriks]

hts, ideas) about something else - in other words, 
> it could be any structure, so we just use a tree. If we subdivided (as indeed 
> we did in the paper), we could posit a number of more specialised data 
> structures.
> 
> 
Really?
I can record as inference (Evaluation) something in the past (as history)
As something inferred now or inferred to happen in the future.
All Evaluations with a history, present and future as do the Observation, 
Instruction and Action.

> 

> See here for Smith/Ceusters/Scheuermann on an ontology for disease course and 
> diagnosis, in which they identify the same categories of information more or 
> less - clinical picture / diagnosis / plan.
> 
> 

They use (to me) a funny definition of 'symptom'.
But as realist ontologists they know that diseases whether diagnosed or not, 
inferred or not are occurrents (processes) with times attached to it.
> So to summarise, it came down to finding categories on which health 
> information data structures - i.e. information models - could be based that 
> would work reliably for most if not all of medicine. Now, having used these 
> categories for some years, it turns out that they are remarkably stable. I 
> know that the grey-zone debate on Observation/Evaluation will continue for 
> ever, but if one steps back for a second, what you see is that for most types 
> of clinical data, it is obvious which category to use. Most of the archetypes 
> for these types are not really in question. Further, noone has identified (to 
> my knowledge) a strong contender for any new kind of category (excepting for 
> sub-categories of AdminEntry, which will probably appear one day). 
> 

On the contrary, in spite of your  claimed years of experience, I have my claim 
to experience both in the openEHR world and that of the EN13606 association and 
this experience shows that they way users use the definitions in openEHR give 
rise to problems for the users. I agree that nobody will annotate a Blood Sugar 
Measurement result as an Evaluation or Instruction or Action.
In literature I have seen many wrong annotations because of problematic and 
unclear  definitions in the real of openEHR.
Why are we having this discussion if there were no problems what so ever?

> I think the main thing we got wrong was naming 'Evaluation' too narrowly, 
> when what we needed was a name that means 'what the clinician thought' (if we 
> had used Sowa's 'description' category I am sure we would now be having 
> arguments about why someone was using a 'description' to record a 
> 'diagnosis'!). We would know we had gotten things radically wrong if now, 5 
> years later, it were clear that say another 5 or 10 data structure types were 
> needed. 
> 
I disagree.
When a clinician is listening to heart murmurs as part of the physical 
examination I can assure you he is listening and thinking a lot, because it is 
very subtile what he is listening to.
Idem dito for palpation, smelling, etc. And there are more examples.

It is not whether he is thinking as a mental process but what matters is what 
is the relationship with the patient system.
Is he thinking about an observable?
Or is he thinking, inferring, about (disease) processes on the basis of 
observables.

For an Evaluation it is clear that it is about a process (continuant) in the 
patient system and that by definition it is an inference.


> If indeed we managed to get this sort of right (for now), it's only because 
> we had 3 previous attempts (GEHR 1992-95; Australian GeHR (1997-2000), first 
> draft of openEHR (pre-2005)) where we got it wrong. 
> 

The word Evaluation is OK.
But we need the correct not confusing definitions with good discriminators to 
make judgements easy.


> This is a hard problem to solve. In HL7v3, it was attempted with the 'mood' 
> code, which is certainly a reasonable starting point philosophically, but 
> doesn't in the end help you get the right data structures. This is well known 
> in HL7v3 as a difficulty (and I am not criticising for that, as I say our own 
> little effort was 10 years in the making). 
> The really amazing thing is that traditional epistemological categories are 
> of such little help. Divisions of a priori / a posteriori / how-to are only 
> vaguely useful (we used them and gave up on Aus GeHR), and yet to a 
> clinician, the differences between the observation of blood glucose over 
> 9mmol/l, Dx of diabetes mellitus and insulin care plan for glucose management 
> are crystal clear.
> I don't doubt that something better is possible in the future, but I think 
> for now some finer adjustments on the current ontology and data structures 
> will be of most practical he
> 
I can only point at our efforts dealing with semantical annotations in the 

Regarding the role of ITEM_STRUCTURE

[Gerard Freriks]

Sam,

According to me:
- Observations have in reality points in time or ranges attached to it
- As do Evaluations about processes in the patient system they  have in reality 
times attached to them. Inferences are made at a point in time, but relate to 
inferred processes that come and go, or are believed to be present, or not, 
during a period of time.
- As do Instructions
- As do Actions

Time is never is a discriminating factor that sets Observations apart from the 
other Entry types.

Gerard Freriks
+31 620347088
gfrer at luna.nl




On 21 Jun 2012, at 14:21, Sam Heard wrote:

> Hi Diego
> 
> I think David Ingram has made a valuable contribution; these are empirical 
> solutions to real problems in real systems. The reality of OBSERVATION is 
> that it deals with point in times, intervals ( max, min etc) and analogue 
> readings. These need to be handled consistently or we end up with 
> combinatorial explosion - lab glucose in LOINC is over 200 codes.
> 
> Satre said that "belief is confusing things with their names". We need to 
> look at the classes and the utility provided. When we have a small number of 
> archetypes there is no doubt we can manage these things with slots etc. But 
> this requires massive alignment very early in the piece.
> 
> Cheers, Sam
> 

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120621/997972a8/attachment.html>

Archetype authoring attribution

[Gerard Freriks]

David,

openEHR:
Creative Commons license CC-BY-SA 2.0, applying to all openEHR.org achetypes 
hosted at the openEHR Clinical Knowledge Manager (CKM).
http://creativecommons.org/licenses/by-sa/2.0/

My simplistic understanding.

A derived work has to be derived.
So when you use the information and transpose it as constraints on an other RM,
then I consider this new archetype as derived from that new RM it is transposed 
to.
So when this approach is followed then the Attribution is to the group that 
provided the clinical content.
But there is no attribution to the openEHR RM specification.

When you translate the text in the openEHR archetype to Dutch it is derived but 
still derived from the original openEHR RM.
In this case attribution must be stated to openEHR RM and the clinical group.

Is this an answer?



Gerard Freriks
+31 620347088
gfrer at luna.nl




On 22 mrt. 2012, at 13:03, David Moner wrote:

> 
> Hello,
> 
> Back again with the licensing topic of archetypes, with a real use case.
> 
> We have been asked to help in creating a set of 13606 archetypes for breast 
> and prostate cancer. Although they will probably incorporate some new 
> requirements, the main source will be some of the openEHR archetypes 
> available at the CKM.
> Assuming that the have adopted a CC-BY(-SA) license (I cannot recall which is 
> the state of that discussion), the doubts are the following:
> 
> - Converting the archetype to a new reference model is considered as a 
> derivation? Or the openEHR archetype is considered just as a reference 
> material as could be any textbook or paper?
> - The author of the new archetype has to be the one of the openEHR archetype 
> (Ian McNicoll btw) or the person who in fact creates the new RM-based 
> archetype?
> 
> The underlying question here that should be clarified is to define which is 
> the extension of the concept "derived work".
> 
> David

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120322/eca31ee3/attachment-0001.html>

13606 revisited - list proposal

[Gerard Freriks]

Dear Erik,

My personal thoughts and reactions.

It is based on off-line discussions in the EN13606 Association.
We will collect our thoughts and ideas, present them next year to the community 
and discuss them in February during our annual meeting in Seville.
Until then my personal ideas only.

Gerard Freriks
+31 620347088
gfrer at luna.nl




On 16 dec. 2011, at 12:06, Erik Sundvall wrote:

> Hi!
> 
> On Fri, Dec 16, 2011 at 09:32, David Moner  wrote:
>> In any case, this generic design is a result of the current scope of 13606:
>> EHR exchange and not a complete EHR implementation specification.
> 
> Thanks for reminding me.
> 
> I tend to forget that the 13606 purpose never was to make internal
> system semantics interoperable. It's easy to forget the intentional
> 13606 focus when usually thinking of mappings and interoperability
> issues based on examples like the ones on slides 12 and 13 of...
> http://www.imt.liu.se/~erisu/2011/openEHR-TBMI19-lecture.pdf
> 
> As you know, if you want to truly bi-directionally share things for
> which it is impossible to define deterministic conversion
> algorithms/programs (thus maintaining patient safety in automated
> conversions), then just defining a standard message- or extract format
> will be a lost cause (no matter how determined politicians are and no
> matter how much you pay IT-consultants to try to do the job). Instead
> the semantics of the end point systems will need to be aligned sooner
> or later.
> 
> Anyway it wouldn't hurt if a new or refreshed internationally
> recognized standard could be used by those vendors and system owners
> that actually _want_ to agree on the internal clinical semantics of
> efficiently implementable systems all the way down to some of the
> technical (e.g. openEHR inspired) details. I think there is now a
> market for such a standard (or new standard part) helping those that
> have given up beliefs in mapping of incompatible semantics.

I agree.
This is what I wanted in the first place.
In the standardisation process it was felt to be more safe to obtain 
experiences first this the present scope.
Some wording in the present scope hints at this more extended use outside of 
the EH-Extract.

Although I agree, I think, that the 13606 Reference Model should not be a model 
on how to implement it in a very detailed way in a system.
It must stay a generic and logical model that provides features that help 
vendors to produce such internal proprietary implemented models.

> 
>> From our
>> experience, interoperability between legacy systems (standard-based or not)
>> is much easier using a generic model for exchange. The harsh truth is that
>> the quality of the data and the design of information structures in existing
>> EHR systems is quite bad or unclear, thus making really complicated the
>> process of automatically transforming it to a very specific reference model.
>> This is not the case when we use 13606.
> 
> I suspect this is an intentional difference between current 13606 and
> openEHR; to faithfully capture the current (incompatible) situation
> versus aiming to change the current situation.  Can those different
> goals really meet in one RM or do we need two standardized RMs?
> http://dilbert.com/strips/comic/2011-08-02/

It is/was a matter of scope.

I see no reason why we can NOT have one logical model that can serve the 
purpose of use inside IT-systems and outside an IT-system.
A different matter is whether the present openEHR RM is acceptable or not.
And who owns the spec.



> 
> A side-track question: Do you feel that the archetyped approach with
> 13606 really helps in the current mappings/transformations that you
> work with more than what just using e.g. RDF+OWL would help? Or does
> the archetype stuff and RM mostly complicate things?

When it is possible to design and implement using 13606 and archetypes in less 
than a week a common patient summary between two different hospitals, or a 
system that transforms a proprietary EHR to the CDISC-ODM format,
is that enough of an answer?
My answer is that the present 13606 fulfills its scope and is very functional.



> 
>> A different thing is if 13606 scope changes during the revision. In that
>> case, I agree that reducing layers of modelling by introducing specific
>> classes will make the systems more efficient.

David and I agree.

> 
> Is there an opening for scope-change or not within the formal
> 13606-revision or would one need to start a completely new standard in
> order to define a standard for aligning internal EHR system semantics?

In the EN13606 Association community there are openings to do that.
But whether the CEN/ISO representatives want it, is to be found out.


> 
> Could one add a new part (13606 part-6 or 1b?)

13606 revisited - list proposal

[Gerard Freriks]

Dear Erik,

Some personal comments in the text below.

GF



Gerard Freriks
+31 620347088
gfrer at luna.nl



=
On 15 dec. 2011, at 15:02, Erik Sundvall wrote:

> Hi!
> 
> On Thu, Dec 15, 2011 at 08:52, David Moner  wrote:
>> The unofficial renewal process of 13606 (or pre-SDO process, as you prefer
>> :-) will start next February at the EN 13606 Association General Assembly in
>> Seville with an open and public consultation.
> 
> Is there any formal link between the 13606 Association and the actual
> standardisation process or is the "pre-SDO process" to be seen as
> traditional lobbying?

There are personal bonds.
The EN13606 Association has asked for a formal Liaison status with CEN/tc251. 
ISO/tc215 will follow.



> 
> Perhaps the best thing would be if the 13606 Association and openEHR
> could bring forward a unified co-authored suggestion to the SDO
> process rather than two suggestions? Perhaps we can use the new
> mailing list Thomas suggested for mail conversations combined with the
> wiki of the EN 13606 Association, instead of having separate mailing
> lists and separate wikis for the alignment discussions in each
> community?

Yes: that would be nice.
No: it is not essential.


> 
>> Before that, to prepare a
>> draft starting point, during January a consultation will be made to key
>> actors, implementers and users of the standard, including openEHR.
> 
> A great thing would be to actually have at least two independent
> _implementations_ of change suggestions (both AM and RM) after initial
> discussions but before any revisions to the standard are made. That is
> how some other SDOs work with technical artefacts and it could avoid
> some of the previous suboptimal approaches.

So you agree with my NO.


> 
> I assume AOM 1.5 is a candidate for AM? Is anybody already working on
> an AOM 1.5 implementation in addition to Tom's Eiffel version? Are
> there people interested in updating the Java implementation (or some
> other implementation) before or during the SDO process?

I think that some additions to AOM 1.5 will be supported by us.

And we will have new requirements, possibly.



> 
> Regarding the RM I know Tom is experimenting with simplified
> ITEM_STRUCTURE as a BMM-schema for the AWB. Are there any other
> RM-redesign experiments going on anywhere?

In my personal thinking the model around the  Entry, Cluster and Element will 
be simplified.
We need to reduce the number of degrees of freedom producing archetypes.
This is an important driving factor behind the new requirements based on our 
experiences producing archetypes.

In addition I'm of the opinion that in the Composition and Section the Entry 
Class must be 'reached' via a reference to an existing committed Entry, only.
In this way there is a more strict separation between functionality dealing 
with presentation/structure and the essential clinical relevant data and 
information that is documented.

These new RM's are not tested in working EHR applications.
They are 'tested' in a sense because we investigate what kind of archetypes can 
be produced.
And whether the number of degrees of freedom is less, but sufficient.


> 
> What is happening in the 13606-world regarding thoughts about
> practical datatypes?

My personal ideas:
- in Archetypes we need to have defined a set of "Leaf-node-Type", being 
indications what a healthcare provider can expect. 
For the techie it is an indication what real data type will be used.
- We need at the minimum the CEN data types, with exclusion of the ordinal data 
type, because at a higher level we will define 'Semantic Ordinals' as 
subpatterns used to model archetypes.
These 'Semantic Ordinals' have additional functionality so more than one can be 
selected, the order in which presented can be recorded, additional inclusion 
and exclusion criteria and signaling range plus attached value that can be used 
for calculations.
- It would be nice, but not essential, to have these 13606 datatypes as 
profiles of the ISO standard.


> 
> What about (optional) reusable ENTRY subtypes in the 13606 world? (see
> http://www.openehr.org/mailarchives/openehr-technical/msg05285.html
> under the heading "2. OBSERVATION et. al. (ISO 13606 CR)")

We need to be able to use specialisations of the Entry class.
My thinking is that these health specific specialisations ( Observation, 
Evaluation, Instruction, Action, etc.) must not play a role in the RM.

We are working on an addition to the 13606 standard that defines how semantic 
interoperability artefacts are structured, used in other semantic artefacts, 
how standardised modeling patterns are used, etc.
In this scheme all these things define a standard for the semantic layer on top 
of the

13606 revisited - list proposal

[Gerard Freriks]

Dear Pablos,

Internally in the EN13606 Association I started to work on this renewal.
The EN13606 Association will start to think about all 5 parts of the standard.

With respect to 13606 part 1 - the reference model- I think we will have 
discussions on topics such as:
- scope
- Folders
- Semantic links
- the structure below the Entry Class
- the type of relationships between the Composition/section classes used to 
structure documents and the Entry, Cluster and Element classes that define the 
clinical content.

Possibly other members will have their own topics they want to put on the table.
In our EN13606 Association meeting in February in Seville we start the 
discussions after a consultation phase.
openEHR will be part of this consultation phase. Any input from openEHR is 
welcomed.
A WIKI page will be started anytime soon on our website.
After these discussions our suggestions will be submitted to CEN/tc251 and 
ISO/tc215.

For more information about the EN13606 Association and the Seville meeting I 
refer to:
www.en13606.org
Non-members that want to participate in this meeting are invited to subscribe.

Gerard Freriks
+31 620347088
gfrer at luna.nl




On 15 dec. 2011, at 05:03, pablo pazos wrote:

> Great! this will be THE opportunity to think about an IM 2.0, and the first 
> topic on my wishlist is the simplification of ITEM_STRUCTURE & children :D 
> 
> -- 
> Kind regards,
> Ing. Pablo Pazos Guti?rrez
> LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez
> Blog: http://informatica-medica.blogspot.com/
> Twitter: http://twitter.com/ppazos

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20111215/0d9c5f74/attachment.html>

Templates, node identifiers and data instances

[Gerard Freriks]

Safari worked fine

GF

Gerard Freriks
+31 620347088
gfrer at luna.nl




On 19 Nov 2010, at 16:55, Sebastian Garde wrote:

> Hi Seref,
> 
> I have the same problem sometimes with PDFs from the openEHR space in Firefox.
> Often it works, but sometimes I get the error you experience.
> 
> Regards
> Sebastian

Interoperability with HL7

[Gerard Freriks]

Stef,

It is a good step.
But not sufficient.

That OpenEHR artifacts are published with such a Creative Commons License 
policy attached to it is a good thing, I agree.
But when a new Reference Model, Archetype Model, Template models change and are 
published that decision is made by the owners because they own the IP and can 
issue any new License policy they wish.

Our customers do not want to be held hostage when they invest in the exiting 
new technology based on En13606/openEHR.
They are taking enough risks already, they feel.

Gerard



On 10 feb 2010, at 15:09, Stef Verlinden wrote:

> 
> Op 10 feb 2010, om 14:32 heeft Gerard Freriks het volgende geschreven:
> 
>> I agree that the form of the company is not the issue.
>> What is important who controls the IP.
>> All Archetypes/Templates/ DCM's must be in the public domain, as is 
>> language, as is HL7 CDA, as is EN13606, as are ISO standards, XML, etc, etc.
> 
> 
> If you read my reply to Bert, which probably crossed your response, you can 
> see that all archetypes are available under CC-BY-SA license. Unofficially 
> since Okt 2009 and officially since Jan 1th 2010
> 
> Do you agree that this means that all openEHR archetypes are in the public 
> domain and that since these archetypes fall under the CC license is really 
> doesn't matter who controls them?
> 
> 
> Cheers,
> 
> Stef

Gerard Freriks
+31 620347088
gfrer at luna.nl

Interoperability with HL7

[Gerard Freriks]

Bert,

There is only one answer.
Hospitals we talk with have problems with the way  IP is handled by openEHR.
IP owned by two organisations (One UCL and the other Ocean Informatics) they 
consider not PUBLIC.

I agree that the form of the company is not the issue.
What is important who controls the IP.
All Archetypes/Templates/ DCM's must be in the public domain, as is language, 
as is HL7 CDA, as is EN13606, as are ISO standards, XML, etc, etc.


Gerard


On 10 feb 2010, at 14:07, Bert Verhees wrote:

>> 
>> It is imperative that DCM's are absolutely free to use and in the public 
>> domain. CEN/ISO and ANSI assure that with the standardisation IP rules in 
>> general.
>> DCM's must be absolutely free from IP problems, well maintained in a formal, 
>> flexible, organisation, owned and controlled by all that use them.
>> OpenEHR as we know it today is a private company. (See under Status: 
>> http://www.openehr.org/about/foundation.html)
> It is not the juridical status of a company that makes the difference for the 
> IP-status of something. If an organization is not-for-profit or for-profit, 
> both can issue all kinds of IP-licenses.
> The company form has nothing to do with the licenses it issues
> 
> Bert
> ___

Gerard Freriks
+31 620347088
gfrer at luna.nl




-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100210/a4107fba/attachment.html>

Interoperability with HL7

[Gerard Freriks]

Dear Stef,

It is simple.
Customers demand Archetypes that are completely free ti use in a commercial 
product.
All openEHR artifacts have an IP owned by a a not-for-profit company with two 
owners.
For academic use it is free. But for commercial use things are not free.

Archetypes/Templates and Detailed Clinical Models must be completely public, 
owned democratically by all.

The present situation is not good for business at all.

I'm as a fervent supporter of the ideas behind EN13606 as ever.
We need requirements for DCM's (and Archetypes) that go beyond the present ones.

With regards,

Gerard


On 10 feb 2010, at 13:05, Stef Verlinden wrote:

> 
> Op 10 feb 2010, om 11:37 heeft Gerard Freriks het volgende geschreven:
> 
>> It is imperative that DCM's are absolutely free to use and in the public 
>> domain. CEN/ISO and ANSI assure that with the standardisation IP rules in 
>> general.
>> DCM's must be absolutely free from IP p! roblems, al, flexible, 
>> organisation, owned and controlled by all that use them.
>> OpenEHR as we know it today is a private company. (See under Status: 
>> http://www.openehr.org/about/foundation.html)
> 
> Hi Gerard,
> 
> 
> What has happened? For years and years you have been the initiator of many 
> disputes between 13606/openEHR and HL7 and! now all to have become the 
> 'enemy'. 
> 
> OpenEHR is a not-for profit organisation and it's knowlegde is in the open 
> domain. If you had Googled around a litte bit you could have found the 
> following:

Gerard Freriks
+31 620347088
gfrer at luna.nl




-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100210/210599a9/attachment.html>

Fw: Interoperability with HL7

[Gerard Freriks]

> ISO Archetypes could, as long as they were modelled in a fashion that is 
> neutral to final implementation format.

It is imperative that DCM's are absolutely free to use and in the public 
domain. CEN/ISO and ANSI assure that with the standardisation IP rules in 
general.
DCM's must be absolutely free from IP problems, well maintained in a formal, 
flexible, organisation, owned and controlled by all that use them.
OpenEHR as we know it today is a private company. (See under Status: 
http://www.openehr.org/about/foundation.html)


> 
> A common format would require both sides to either map the generic structures 
> into their own specific classes or adopt a more generic model with the 
> semantics in the terminology. The overlap between the information model and 
> the terminology model is probably at the heart of the conflict.

I produced (but not published) a draft document with the DCM Ontology as 
addition to the EN13606 and my thoughts about the next version of EN13606.
But also with my thoughts about the Boundary problem with coding systems and 
ontologies.

In collaboration with the Technical University in Valencia we started a project 
to think about the next version of EN13606.
For this purpose a website is created as focus point for discussions: 
www.EN13606.EU

> 
> Andrew McIntyre




Gerard Freriks

Electronic Record Services B.V.

Ditlaar 7
NL-1066 EE Amsterdam
PO Box: 376, NL-2300AJ Leiden
the Netherlands

M: +31 620347088
E: g.freriks at e-RecordServices.EU
W: www.e-recordservices.eu

Gerard Freriks
+31 620347088
gfrer at luna.nl




-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100210/88f76f5f/attachment.html>

Layers of interoperability, OWL and openEHR

[Gerard Freriks]

Hi Charlie,

I agree.
This topic is not about HL7 and/or EN13606.
It is about the logical, semantic and technical aspects of semantic  
interoperability.

I like to think about problems using simple, time proven, solutions  
and ways to deal with complexity.
One magic solution for everything is impossible.
We humans use the dictionary to describe the meaning of words.
Using a syntax we produce sentences.
With common knowledge in our heads we know what is relevant and makes  
sense.
We express what we need to express in a context.

The dictionary will not tell us what to document.
We need a way to capture what we want to express.
We all use documentation patterns to express things in a common way.

Mental exercise:
- Documentation Pattern: " Once upon a time there was a Princess"
We humans know that it is the documentation pattern for a fairy tale.  
Will the ontology be able to 'know' this?
Probably not. It will assume: there was a princes, there was a time,  
there was a place.

I see the need for six orthogonal levels (models).
1- A structure describing knowledge = the Ontology
2- Words to express knowledge = Coding system
3- Something else
4- A structure to assemble words into sentences
5- A structure to assemble sentences in documents
6- A structure to store meta-information for archiving purposes,  
versioning, etc, etc.

Without 3 we are able to produce correct sentences and collect them in  
documents.
This does not guarantee that we produce relevant sentences in a  
particular context.
It does not guarantee that sentences produced make sense; they can be  
non-sensical.
Even when they are correct the documentation pattern causes the  
interpretation to change completely.
Using 1 we (and IT-systems) will find out that it is nonsense and not  
relevant in a context.
Therefor we need a structure so users can express want they want to  
express.
This level three are Archetypes/Templates.

Level 3 is the Documentation Pattern where context, processes, humans  
interact with systems and use all the other layers to document,  
archive, exchange and re-use heir data and information.

At level 3 we must know how technically we can refer to codes from  
coding systems.
I know that we have not a universal way to refer to codes and coding  
systems.

Do we have a worldwide agreement how we refer to a coding system?
Do we have a worldwide agreement how we refer to a specific code from  
a coding system?
Do we have a worldwide agreement how we refer to a defined subset of  
codes from a coding system?
How do we deal with the variable structure of each code?
Do we have a worldwide agreement how to process the presentation  
labels and descriptions?
Do we have a worldwide agreement how to express inclusion and  
exclusion criteria (in the case of classifications for example)?
Do we have a worldwide agreement how we deal with the language in  
which code and coding system  related items are expressed?
Do all standards, systems, specify all  this in universal way?

Gerard


--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On Apr 23, 2009, at 9:39 AM, Charlie McCay wrote:

> I would agree that there are limits to the utility of such mappings  
> -  indeed it is to explore such limits that we are engaged in this  
> thread.
> This is a serious area, and openehr, 13606, and hl7 all have  
> mistakes and successes, (and differences and similarities). We have  
> differing perspectives on those, but let's try to put that to one  
> side and address common themes in this thread.
> I agree that there is a difference between language and ontology. I  
> am less convinced that to serve clinical system interoperability the  
> distinction can be maintained absolutely. At one level there is the  
> blurred boundary between terminology and structure, and at another  
> there is the safe automated reuse of entries/clinical statements -  
> something that happens and for which we need a better understanding,  
> with entries being treated as semantically independent.  I beleive  
> that ontologists have much to contribute to this area.
> I share with Seref a desire to understand why the research work is  
> not getting into practice. If it is not addressing the practical  
> questions then I move on to ask what work is.
>
> My interest is in asserting the relationships between standards  
> relevant to interoperability. I beleive that there is value in  
> seeing what is stopping this happening, and whether the cost of  
> addressing some or all of those hurdles would be justified
>
> All the best
>
> Charlie

-- next part --
An HTML attachment was s

Layers of interoperability, OWL and openEHR

[Gerard Freriks]

Dear Seref,

HL7 made serious mistakes.
They used the RIM to model the real world events and documentation  
about it.

Mixing two different types of models is impossible.
The best that can happen is that in one model-world one refers to  
constructs in the other world.

Models of reality.
Ontologies are models of reality and in semantic interoperability we  
use them to construct lists of codes, labels and descriptions.
Because of the ontology we are able to make inferences, to express  
knowledge behind the lists of codes, labels and descriptions.
Because of the ontologies we are able (eventually) to make  
applications more intelligent and kind of let them reason.

Models of documentation.
EN13606/openEHR and HL7v3 CDA are models that help people document  
data and information.
It helps them archive, exchange and re-use.
All data and information stored, is stored with all contextual  
information and meta-information about the documentation process.
Models of documentation store data and information in named chapters,  
sections, paragraphs.
They allow users to write complex sentences, using documentation  
patterns humans agreed upon.
They use words from dictionaries (coding systems, terminologies,  
classifications and code lists).
They never map to ontologies. Should never map to ontologies and vice  
versa.

Any attempt to try to map Ontologies to Syntax structures is bound to  
fail.
It is squaring the circle.

Gerard

--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On Apr 22, 2009, at 11:06 PM, Seref Arikan wrote:

> Hi Charlie, a couple of good points! Comments are inline.
>
>
> I am working on how the NHS Logical Record Architecture (LRA)  
> asserts conformance/compliance to external standards.   One thing  
> that is required is a semantic mapping between the LRA  
> specifications and the external standard.  Initially I am mainly  
> interested in mapping the static models. (Reference models,  
> datatypes, templates, archetypes, etc)
>
>
> Great starting point. My question is: let's  assume you'll have the  
> complete mappings tomorrow morning, given to you by someone. For  
> now, let's say they are expressed in OWL. All the possible mappings  
> for static models you've liste are complete. Now, what would you do  
> with them? I'd love to hear your use cases for the situation where  
> you have these mappings.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090422/e22d7d90/attachment.html>

Layers of interoperability, OWL and openEHR

[Gerard Freriks]

Dear Seref
As a more technical continuation:
When ontologies and syntaxes are orthogonal the two meet in one place
At that spot on the syntax will refer to a code from a coding system  
(terminology, classification, code list)
Technically it boils down to how semantically correct and safe can we  
define this reference?

Ontologies can play a role in the prlduction of codes

Gerard


Sent from my iPhone

On 22 apr 2009, at 15:26, Seref Arikan  wrote:

> I am happy to see responses in the non-technical level too. Well, in  
> case someone has a technical comment regarding binding ontologies to  
> archetypes and openEHR RM objects, I'll be around :)
>
> Kind regards
> Seref
>
> On Wed, Apr 22, 2009 at 12:06 PM, Ian McNicoll  oceaninformatics.com 
> > wrote:
> Can I suggest moving this to the Clinical list? I think it is an
> important subject ,and rather dear to my own interests but, as Thomas
> pointed out, we are in danger of submerging Seref's original more
> technical question.
>
> Any objections?
>
> Ian
>
> Dr Ian McNicoll
> office / fax  +44(0)141 560 4657
> mobile +44 (0)775 209 7859
> skype ianmcnicoll
> ian at mcmi.co.uk
>
> Clinical Analyst  Ocean Informatics ian.mcnicoll at oceaninformatics.com
> BCS Primary Health Care Specialist Group www.phcsg.org
>
>
>
> 2009/4/22 Gerard Freriks :
> > Dear Seref,
> >
> > Ask yourself the question:
> > How do we, humans, deal with interoperability?
> >
> > Do we humans use formally expressed ontologies using OWL.
> > Do we use rigid formal syntaxes where we use strictly defined formal
> > terms.
> > Do wet have to express a measurement in DV-Quantity as Double or
> > Floating Point with Precision x.
> > All this is the world of zero's and one's, bits and bytes and IT
> > industry.
> >
> > We humans have a vague knowledge of many concepts in our worlds.
> > We have a very flexible syntax and many, many terms. We even invent
> > new ones.
> > It is a chaotic system based on a limited set of rules with emergent
> > behavior.
> > We express what we want to document using documents, chapters,
> > sections, paragraphs, words and characters.
> > This is the world of documentation, concepts, humans.
> > This the magnificent world of language, prose and poetry.
> > Where on the basis of a limited set of rules we can document  
> everything.
> >
> > It is clear that both worlds (IT and Humans) overlap in certain  
> areas.
> > But mostly the do not overlap.
> > Do not mix them up and when you do, we get confused and create  
> monsters.
> > Both worlds have to stay absolutely orthogonal to each other.
> >
> > Any interoperability solution where notions, ways of thinking and
> > expressing, from the IT world with bits and bytes are enforced on
> > humans, will create problems.
> > Solutions should start at this human documentation/language level.
> >
> > The EHR is about documentation of events/facts/thoughts/ideas for
> > human consumption primarily.
> > IT-systems should support this. That is all we need for now.
> > We can try to model real life using the formal, rigid, technical  
> ways.
> > And create something that doesn't fit the needs of humans or relates
> > to this human world.
> > Or we use IT and models to support humans to document what they feel
> > they need to document.
> > Humans are not very precise but language works rather efficiently  
> and
> > well enough.
> >
> > Modeling knowledge in ontologies is an interesting academic  
> exercise.
> > Modeling the complex real life is an interesting academic exercise.
> > But...
> > Let humans use words freely, either as free text of better from a
> > common controlled flexible resource (dictionary=coding system/
> > terminology/classification).
> > Let humans use words in a syntax (Reference Model) to create freely
> > all sentences/screens (Templates) they need using agreed  
> documentation
> > patterns (Archetypes), using tools based on an Archetype Model.
> >
> > And that for the moment is good enough at this point in time looking
> > for the Holy Grail called Semantic Interoperability.
> >
> > Gerard
> >
> >
> > On 21, Apr, 2009, at 12:25 , Seref Arikan wrote:
> >
> >> Dear members of the list,
> >> I'd appreciate your opinions and guidance about a particular topic.
> >> As most of you probably know, the work in the ontology domain has
> >> been the flagship of semantic interoperability for many projects
> >> now, and there is a large 

Layers of interoperability, OWL and openEHR

[Gerard Freriks]

Dear Seref,

Ask yourself the question:
How do we, humans, deal with interoperability?

Do we humans use formally expressed ontologies using OWL.
Do we use rigid formal syntaxes where we use strictly defined formal  
terms.
Do wet have to express a measurement in DV-Quantity as Double or  
Floating Point with Precision x.
All this is the world of zero's and one's, bits and bytes and IT  
industry.

We humans have a vague knowledge of many concepts in our worlds.
We have a very flexible syntax and many, many terms. We even invent  
new ones.
It is a chaotic system based on a limited set of rules with emergent  
behavior.
We express what we want to document using documents, chapters,  
sections, paragraphs, words and characters.
This is the world of documentation, concepts, humans.
This the magnificent world of language, prose and poetry.
Where on the basis of a limited set of rules we can document everything.

It is clear that both worlds (IT and Humans) overlap in certain areas.  
But mostly the do not overlap.
Do not mix them up and when you do, we get confused and create monsters.
Both worlds have to stay absolutely orthogonal to each other.

Any interoperability solution where notions, ways of thinking and  
expressing, from the IT world with bits and bytes are enforced on  
humans, will create problems.
Solutions should start at this human documentation/language level.

The EHR is about documentation of events/facts/thoughts/ideas for  
human consumption primarily.
IT-systems should support this. That is all we need for now.
We can try to model real life using the formal, rigid, technical ways.  
And create something that doesn't fit the needs of humans or relates  
to this human world.
Or we use IT and models to support humans to document what they feel  
they need to document.
Humans are not very precise but language works rather efficiently and  
well enough.

Modeling knowledge in ontologies is an interesting academic exercise.
Modeling the complex real life is an interesting academic exercise.
But...
Let humans use words freely, either as free text of better from a  
common controlled flexible resource (dictionary=coding system/ 
terminology/classification).
Let humans use words in a syntax (Reference Model) to create freely  
all sentences/screens (Templates) they need using agreed documentation  
patterns (Archetypes), using tools based on an Archetype Model.

And that for the moment is good enough at this point in time looking  
for the Holy Grail called Semantic Interoperability.

Gerard


On 21, Apr, 2009, at 12:25 , Seref Arikan wrote:

> Dear members of the list,
> I'd appreciate your opinions and guidance about a particular topic.  
> As most of you probably know, the work in the ontology domain has  
> been the flagship of semantic interoperability for many projects  
> now, and there is a large amount of researchers active in the field.
> I've been involved in use of ontologies for semantic  
> interoperability for the first time in 2002, and since then,  
> ontologies have become a frequently pronounced solution for a large  
> set of problems.
> However, I have a feeling that the nature of this work creates just  
> a layer in the multilayer interoperability space. Expressing  
> relationships among different entities and doing this in a formal  
> way (OWL) is nice. OWL also allows you to do processing, reasoning  
> on the defined relationships, but unless I'm missing something, this  
> is all about relationships, and concepts. I mean the capabilities of  
> OWL seem to be valid in the relationships is defines.
> What about the actual things, data items, entities that OWL links  
> together? I've been a proponent of well defined type systems and  
> object hieararchies in healthcare interoperability solutions, since  
> I've spent years in the software development side of the domain, and  
> a huge number of issues arise from the developers interpreting  
> losely defined types, or inventing their own types.
> Now pinning down concepts either by using terminologies or  
> ontologies is good. It is good to know that two fields on two  
> different data structures are pointing to the same concept. This  
> however, is the beginning of the process. Pointing at the same thing  
> and processing it in the same way are different things. Just because  
> we agree that we are pointing to body temperature in two different  
> documents does not stop us from processing one of them with a  
> double, and the other one with a float.
> There is a great deal of information out there expressed in the form  
> of OWL, or other formalisms, but I can't see this covering all  
> aspects of interoperability, but (no offense) there is a large crowd  
> out there who think they have solved the problem of semantic  
> interoperability. Though it may be an undervaluation of the work,  
> "mappings" are nice, but they don't ease the rest of the work, where  
> mapped items are processed in different domains

Layers of interoperability, OWL and openEHR

[Gerard Freriks]

Graham,

Exactly.
Somewhere there is a paradox.

Gerard


--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On 21, Apr, 2009, at 21:43 , Grahame Grieve wrote:

> Hi Gerard
>
> Who does understand semantic interoperability?
> The beauty of human interaction is that we can
> get along even without understanding each other.
> And we?ll never get computers to understand each
> other. So we shouldn?t aim for semantic interoperability,
> we should aim for unsemantic interoperability
>
> ;-)
>
> (kudos to the Health IT Nerd)
>
> Grahame
>

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090421/9dd50288/attachment.html>

Layers of interoperability, OWL and openEHR

[Gerard Freriks]

Derek,

Shooting?
No.
I agree with you.
And I disagree.

I think that there are clinical  informaticians that know, implicitly  
or explicitly, about semantics, about language and the philosophical  
aspects.
At least clinicians and nurses do (and most patients and other people)  
since they communicate using voice, writings and gestures.

The problem is that technicians do not understand semantic  
interoperability.
And I must say that many informaticians are actually technicians  
without any understanding of semantics.


Gerard



On 21, Apr, 2009, at 16:17 , Derek Meyer wrote:

> Dear List People,
>
> Another view, and my two (euro) cents, for what they are worth:-
>
> There are many philosophical difficulties in the concept of semantic
> interoperability which technology cannot address. Put simply, semantic
> interoperability requires an agreement on meaning, and meaning is  
> not a
> 'thing'.  Semantic interoperability requires uses of a system to think
> in the same way - or at least in mutually understandable ways - and
> informaticians do not (yet) have the power to change the ways people  
> think.
>
> So semantic interoperability is a kind of philosopher's stone. The
> search for the original philosopher's stone, which could turn base  
> metal
> into gold, simply showed that alchemists misunderstood chemistry and
> sub-atomic physics. Maybe the search for  semantic interoperability
> simply shows that informaticians misunderstand linguistics and the
> nature of knowledge.
>
> OK - you can shoot me down now..
>
> Derek.



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755


-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090421/9a5b3072/attachment.html>

Why is the editor not opening ADL files?

[Gerard Freriks]

Shouldn't we consider to extend the Demographics to  Resources?

Isn't a person one of many types of resources we need to document in  
and around the EHR?
(e.g. devices, catalogs with lab tests or procedures, rooms, beds, ad- 
hoc lists, etc)

Gerard


--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On 5, Apr, 2009, at 11:13 , Thomas Beale wrote:

>
> General principles:
> EHR:
> clinical data
> clinically relevant demographic details, e.g. sex, date of birth,  
> occupation
> but otherwise, identifying information, and even patient id(s) can  
> be avoided completely in the openEHR EHR, or they can be put in; see  
> Common IM for discussion 
> -http://www.openehr.org/releases/1.0.2/architecture/rm/common_im.pdf
> clinically relevant admin data, e.g. admission, discharge, transfer,  
> birth, death, 
> Demographic:
> demographic data of any complexity, including personal contact  
> information, professional qualifications
> relationships, typically for relating professionals together into  
> teams, groups and to employing organisations
>

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090405/2335c793/attachment.html>

CQuantityItem.units not empty

[Gerard Freriks]

Question:

Isn't the pain score a COUNT data type?

Gerard


--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On Feb 10, 2009, at 5:28 PM, Williamtfgoossen at cs.com wrote:

>
> Thomas,
>
> Thank you for your reply, however it does not satisfy the request.
>
> I think that the pain score is indeed not a physical measurable  
> instrument.
> But it is not an Ordinal, in statistical terms it is an Interval if  
> the numeric score is used (0, 1, 2, 3 etc up to 10) and a ratio when  
> the VAS scale is used.
> Hence reliability studies have determined that it is useful in  
> practice.
>
> However, I would like to have the following
>
> DV_PhysicalQuantity meeting the PQ requirements from ISO 21090
> and the
> DV_CodedOrdinal, or DV_Ordinal meeting the requirements for the CO  
> (Coded Ordinal) from ISO 21090.
> The CO does allow the order as we need, and allows the mathematical  
> operations such as summations, calculations like BMI style, among  
> others.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090210/750b8134/attachment.html>

text and description

[Gerard Freriks]

Thomas,

I do not have the details, but I know they use the CEN standard for  
registries.

Francois Mennerat will know more.

Gerard


--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On Dec 1, 2008, at 12:17 PM, Thomas Beale wrote:

> Gerard Freriks wrote:
>> Dear all,
>>
>> The European Institute for Health Records has created a registry of
>> coding systems.
>> In the (near) future they expect to be the place where coding systems
>> and their meta-information are registered so an URL and unique
>> identifying number will suffice.
>>
>> Will this be the way to go?
>
> I didn't know of this body. How does their registry correlate to the
> UMLS list? How do they handle revisions of terminologies? How do they
> handle language variants (including ones that are of earlier  
> revisions,
> or are partial)?
>
> - thomas beale
>

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20081202/d2368708/attachment.html>

text and description

[Gerard Freriks]

Dear all,

The European Institute for Health Records has created a registry of  
coding systems.
In the (near) future they expect to be the place where coding systems  
and their meta-information are registered so an URL and unique  
identifying number will suffice.

Will this be the way to go?

Gerard


--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On 1, Dec, 2008, at 5:26 , Koray Atalag wrote:

> So custom/local terminologies can be handled this way and the  
> implementation will be left to developersBUT this may result in  
> different implementations which may render interoperability in the  
> long run
>
> So I suggest a sub-section within ontology section where used  
> terminologies are declared explicitly; i.e. "umls": 2008AA version  
> of NLM UMLS knowledge sources. Perhaps an URI and other details can  
> be specified (i.e. WSDL). I think it is easier for the community to  
> agree on such a naming convention.
>
> Custom local terminologies can be declared this way and you can  
> create terminology names for use in term/constraint bindings.Perhaps  
> creating a keyword (i.e. CustomTerminology) might be a good idea so  
> that these names do not interfere with formal names.
>
> Cheers,

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20081201/b8d893a6/attachment.html>

Please respond by Friday Nov 7th: Deployment, Version, PATIENTS IN SYSTEM.

[Gerard Freriks]

Bert,

What is the definition of 'closed system'?

When open=not-closed.

Is open source open?
Is a system based on a standard and its implementable specification  
open, also?

Is an essential attribute of 'openness' that the software is open?
Or is an essential attribute  of 'openness' that the data base is open?

Gerard


--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On Nov 6, 2008, at 10:00 PM, Bert Verhees wrote:

>> The question was about Open Source and not about commercial
>> proprietary ehr systems
> Sorry Gerard, there were more closed systems discussed under this  
> topic.
>

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20081106/5ea9a19e/attachment.html>

Please respond by Friday Nov 7th: Deployment, Version, PATIENTS IN SYSTEM.

[Gerard Freriks]

Perhaps you have not noticed

The question was about Open Source and not about commercial  
proprietary ehr systems

Gf

Sent from my iPhone

On 6 nov 2008, at 20:07, "Norbert Lipszyc"  wrote:

> The dbMotion solution, developed in Israel, is today covering nearly  
> 6 million patients in Israel, and 7 million patients in the UPMC  
> installation in the US.
> Norbert Lipszyc
>
> De : openehr-technical-bounces at openehr.org 
> [mailto:openehr-technical-bounces at openehr.org 
> ] De la part de Dr. Irving Buchbinder
> Envoy? : jeudi 6 novembre 2008 16:04
> ? : For openEHR technical discussions
> Objet : Re: Please respond by Friday Nov 7th: Deployment,  
> Version,PATIENTS IN SYSTEM.
>
> Ignatio
>
> Does ANYONE list his/her numbers of patients hosted by the system? I  
> tried to find that number for several larger commercial systems and  
> got the MdD's answer of milliions and milliions (of patients) ... I  
> could find the number of doctors rather easily.
>
> Irv Buchbinder/ FreeMED
>
> On Thu, Nov 6, 2008 at 9:53 AM, Ignacio Valdes   
> wrote:
> Hello all,
>
> The un-official, Draft 8 of the upcoming American Medical Informatics
> Association Open Source Working Group white paper to be voted on
> November 9th can be found http://ignaciovaldes.com/amia. It will be
> voted on for ratification on November 9th-11th or so. Action is needed
> on your part to answer the question: If open source is so great why is
> no one using it? There is no aggregate data that I can find to counter
> this opinion. If you know of a Free/Open Source EHR/EMR deployment and
> could please send three pieces of information on each deployment that
> you have by Wednesday November 7th: General Location, software version
> and most importantly NUMBER OF PATIENTS IN SYSTEM. This paper could
> have national impact with this data. Please respond by email to
> ivaldes at hal-pc.org if you are able to obtain this data.
>
> -- IV
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>
> -- 
> -- 
> Irving J. Buchbinder, DPM, DABPS
>  Director, FreeMED Software Foundation, INC
>  -=Technology advances. People stay the same=-
>  Leigh  
> Rubin
> skype at irvbuchbinder
>
> *** E-MAIL CONFIDENTIALITY ***
> This e-mail may contain confidential and proprietary material for   
> Any review or distribution by others is strictly prohibited.  If you  
> are not the intended recipient  please contact info at freemedsoftware.com 
>  and delete all copies.
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
-- next part --
An HTML attachment was scrubbed...
URL: 

Differential display

[Gerard Freriks]

Hi,

I agree with Heath's opinion.
It is better to present both alternatives and let the application/user  
decide what he wants to see in reality.

But for admission to a record the rule must be: see and inspect both  
before accepting.

Gerard


--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On 19, Aug, 2008, at 2:05 , Heath Frankel wrote:

> I would suggest that duplication of data is better than accidently  
> hiding
> data, especially when the users are used to having two ways of  
> displaying
> the same data.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080819/80a48653/attachment.html>

Differential display

[Gerard Freriks]

HI,

Am I wrong to observe that the differential is not Display and Non- 
Display,
but Structured and Non-Structured?

The problem with the suggestions by Sam is that part of the  
information that is received is not visible.
In order to accept data from a third party I need to see and judge  
both the visible and invisible parts of the Template.

Gerard


--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On 18, Aug, 2008, at 7:06 , Sam Heard wrote:

> Dear All (cross post)
>
> We are working in an environment where many applications and CDA  
> messages have information that is displayed as text and repeated  
> information in structured form. This also arises in applications  
> which have a formatted document plus structured information  
> (typically in primary care).
>
> I am proposing that we have a section archetype to manage this. The  
> archetype display script would not display any information about the  
> section itself (it would be invisible) and would display the first  
> subsection but not the second. The section archetype would be:
>
> Differential display
> Display
> Entries here will display
> Non-display
> Entries here will not display
> This does mimic the CDA approach but does have the added benefit  
> that the displayed information can be structured as well (a  
> requirement from our customers who want to mix the textural content  
> and structured medication orders (ie not duplicate these in the  
> textural display).
>
> If this archetype arrived somewhere where it was not known the  
> generic display script would show the non-display information  
> (twice). This would be unlikely to cause errors especially as there  
> would be a heading Non-display.
>
> So that is the approach that we have considered. There is an  
> alternative - just have a non-display section. This has the  
> advantage that it could be added when required on an adhoc basis.  
> The major problem that I can see is that it would not be clear which  
> part of the record held the information that was redundant (ie where  
> it was being displayed).
>
> I would be interested in people's views of this approach to the  
> redundant structured data problem that arises from CDA and word  
> processor style record applications.
>
> Cheers, Sam
>
>
> Cheers, Sam

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080818/84ad2e06/attachment.html>

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Gerard Freriks]

My spectrum:

- Archetypes (generic documentation patterns)
- Templates (context dependent documentation patterns)
- Generic User Interfaces (generic presentation patterns)
- User Interface (context dependent presentation patterns)

Gerard


--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On Jun 30, 2008, at 3:19 PM, Erik Sundvall wrote:

> Hi!
>
> Thanks for a lot of interesting response regarding "GUI-hints" and  
> other things.
>
> Please excuse a little left-to-right analogy below:
> There seems too be a scale or spectrum of detail level and use case
> specificity going from...
> Left: purely semantic (maximum data set) models = archetypes
> ...via the nearby...
> openEHR templates (still purely semantic if we skip the "hide_in_ui"
> to keep the template artifacts)
> ...further far away to...
> Right: actual GUI in an implemented system with specific widgets  
> positioning etc
>
> Currently openEHR specifications describe artifacts at the "left" side
> of the spectrum. This discussion has interestingly been broadened
> further to the "right" than I was thinking of in my initial questions.
> If we look at a tool like the Template Designer from Ocean Informatics
> there is an immediate jump from templates (close to the left) to
> detailed GUI layout (far right), that jump could be divided into more
> steps (possibly with some steps persisted and reusable) as suggested
> by some in this discussion.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080630/6c380501/attachment.html>

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Gerard Freriks]

Heather,

You are correct.
Do not mix things.
Tools become to complex.
And healthcare providers loose focus.

When designing archetypes we see the archetype screen.
When designing and discussing templates we see the template screen.
But when discussing data entry and data presentation screens we see  
them.

For each its own tooling and ways to present.

Thinking about the presentation aspect:
- There are several levels:
- parts of the data/information that display urgent matters that have  
to be signaled and that this fact needs to be documented.
- local arrangements that deal with conditional context dependent  
presentation, the functionality of a electronic form
- local arrangements that deal with local preferences on location on  
the screen, presentation forms, fonts, colors, etc.

Gerard

--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On Jun 27, 2008, at 2:40 PM, Heather Leslie wrote:

> Hi all,
>
>> From where I sit the issue being discussed here is an old one  
>> essentially
> about human nature - we all respond most easily to that which we  
> know and
> understand.
>
> In designing a website we know that if you want input about  
> navigation, then
> don't have any meaningful content or GUI hints available or almost  
> certainly
> all the feedback will be about the size or color of the button and  
> the font
> and position of the heading.
>
> Similarly my concern in designing templates and getting the content  
> reviewed
> appropriately is that as soon as you add interface/GUI features to  
> make it
> more 'intuitive' to the clinicians their focus goes immediately to  
> that
> which is more familiar.  That is, the feedback tends to be related  
> to their
> user interface experience (naturally gained from their day-to-day  
> use of
> their current clinical system) rather than actually critiquing which
> archetypes have been used, which data fields are presented, and all  
> their
> associated attributes, cardinality, constraints and related metadata  
> etc
> etc.
>
> So my preferred response (and from positive experience) is to spend a
> relatively small amount of time to educate the clinicians on how to  
> feedback
> appropriately and meaningfully on the pure archetypes and templates  
> - we
> have done this successfully, but I suggest it is probably optimal if a
> clinician involved in the design (perhaps a health informatician  
> with a leg
> in 'both camps') to walk them thru the models and to make it a  
> sensible
> conversation.  It is my opinion that the GUI design and review  
> should be
> completely separate to the content design and review - mixing the  
> two gets
> very confusing.
>
> Regards
>
> Heather

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080627/02f94708/attachment.html>

GUI-hints in openEHR templates? (Was: PatientOS archetype to form demo (of sorts))

[Gerard Freriks]

Dear all,

Archetypes are Documentation Patterns for clinical and non-clinical  
topics.
Templates are Documentation Patters used in a specific context. They  
can be considered as agreements/contracts on what to show, store, and  
exchange.
How that content of a Template is represented on the screen is the  
topic of this discussion.

On one hand: Keeps things simple. And things are simple when we  
separate as much asp possible. We separated IT from data and  
Information and it  makes a lot of sense to separate presentation of  
that data and information as well.
On the other: Objects consist of three things: Information, Methods  
and Representation. And the information and representation parts carry  
semantics.
Information represented in black is not the the same as when  
represented on a screen in RED or in CAPITALS or flickering.

Thinking about it:
Data and Information- Arche-Types (and Templates)
Presentation: Presentation-Types
Methods: Method-Types

Each Type its own tool, Model and Language
Plus one tool that integrate all three aspects of the Object.

Gerard


--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





On Jun 27, 2008, at 8:58 AM, Erik Sundvall wrote:

>> One thing I noticed in the conversion that I don't have any way of
>> distinguishing between a line of text and multiline text in the
>> archetype (I would generate an appropriate pane in the latter case).
>> Perhaps not a big deal.
>
> This might be a useful requirement for the current template
> specification currently being worked on, or possibly a new kind of
> related specification.

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080627/783d9c35/attachment.html>

Question on the role of EHR reference models for achieving functional interoperability

[Gerard Freriks]

Dear Georg,

-1-
When interpreting text from standards it is a useful practice to look  
at the definitions.
3.9
electronic health record (EHR) - for integrated care (ICEHR)
a repository of information regarding the health status of a subject  
of care in computer processable form,
stored and transmitted securely, and accessible by multiple authorised  
users. It has a standardised or
commonly agreed logical information model which is independent of EHR  
systems.  Its primary purpose is the
support of continuing, efficient and quality integrated health care  
and it contains information which is
retrospective, concurrent, and prospective
3.10
electronic health record (EHR) ? basic generic form
a repository of information regarding the health status of a subject  
of care, in computer processable form
NOTE The definition of the EHR for integrated care in 3.9 should be  
considered the primary definition of an electronic
health record.  The definition of a basic-generic EHR is given only  
for completeness and to acknowledge that there are still
currently many variants of the EHR in health information systems which  
do not comply with the main (ICEHR) EHR
definition (e.g. a CDR complies with the basic-generic EHR definition  
but not with the ICEHR definition)

3.27
shareable EHR
an EHR with a commonly agreed logical information model
NOTE 1 The shareable EHR per se is an artefact between a basic-generic  
EHR and the Integrated Care EHR (ICEHR)
which is a specialisation of the shareable EHR. The shareable EHR is  
probably of little use without the additional clinical
characteristics which are necessary for its effective use in an  
integrated care setting.
NOTE 2 Whilst the ICEHR is the target for interoperability of patient  
health information and optimal patient care, it
should be noted that the large majority of EHRs in use at present are  
not even shareable let alone having the additional
characteristics required to comply with the definition of an  
Integrated Care EHR.  A definition of a basic-generic EHR has
therefore been included to acknowledge this current reality.


It is clear to me that they defined the EHR as what is called the  
'Sharable EHR'.
Within the light of this definition to have the Reference Model is a  
requirement.

-2-
3.25
semantic interoperability
the ability for information shared by systems to be understood at the  
level of formally defined domain concepts
Semantic Interoperability is more than functional interoperability.
For the latter a piece of written paper or a PDF is enough.
In ISO 20514 one is clearly dealing about full semantic interoperability

-3
When a thing is required most often this is not sufficient by itself.
Other requirements have to be fulfilled in addition.
For semantic interoperability we need terminologies and ways to  
express sensible things in a context (archetypes and templates).
We need in addition a syntax and this is the Reference Model.

-4-
What they actually write and describe as pre-requisites is:
In order to achieve semantic interoperability of EHR information,  
there are four prerequisites, with the first two
of these also being required for functional interoperability:
a) a standardised EHR reference model, i.e. the EHR information  
architecture, between the sender (or
sharer) and receiver of the information,
b) standardised service interface models to provide interoperability  
between the EHR service and other
services such as demographics, terminology, access control and  
security services in a comprehensive
clinical information system,
c) a standardised set of domain-specific concept models,  i.e.  
archetypes and templates for clinical,
demographic, and other domain-specific concepts, and
d) standardised terminologies which underpin the archetypes. Note that  
this does not mean that there
needs to be a single standardised terminology for each health domain  
but rather, terminologies used
should be associated with controlled vocabularies.

In the context of all definitions I read that EHR-systems that have  
only a Reference Model and Service Interface models can interoperate  
at the functional level.
And this is true.
When systems store information using the CEN/openEHR Reference Model  
there is enough information from the RM to represent the data in a for  
humans understandable way.
It then acts exactly as a PDF!
Humans when reading PDF's can interpret only because of their shared  
implicit underlying Reference Model that we know by the name: Syntax  
of language.

WIth regards,

Gerard Freriks

On 24, Jun, 2008, at 12:16 , Georg Duftschmid wrote:

> Dear all,
>
> I would like to ask you for your opinion on a statement in ISO/DTR  
> 20514 (Definition, scope and context of the EHR), which says that  
> "[...] a standardised EHR reference model is required for achieving  
> functional interoperability [...]" (page 7 of ISO 20514).
>
> Functional interoperability is defi

Decision Support was: MIE-2008

[Gerard Freriks]

Dear Tmo,

I'm glad that you agree about 'patterns for documentation' as  
presented by Archetypes.

And yes. The archetype approach will enable us to have an ever  
evolving way of express new things or in new ways.
But in the end we need an atomic concept that we will always use in  
our thinking.
And this concept to my idea is the 'documentation pattern' as an  
almost never changing, stable element, we can reuse all the times.

A collection of Documentation Patterns and codes from coding systems  
will become these 'atomic' elements.

Gerard



On 14, Jun, 2008, at 18:10 , Thilo Schuler wrote:

> Obviously, this needs a good governance structure (like oceans
> knowlege manager environment). And certain basic patterns should be
> provided as role models to stimulate the process and avoid too many
> "beginners mistakes". This is what we - early clinical users with some
> technical insight - should  come up with.



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080614/d1923106/attachment.html>

Decision Support was: MIE-2008

[Gerard Freriks]

Dear all,

It is all about patterns for documenting.

I agree that inspection of the present collection of openEHR  
archetypes and those produce by the NHS are a nice resource.
But we must realize that these were produced for demonstration,  
testing, learning or the collection of information requirements.
The Templates and Archetypes we need must be designed for semantic  
correct, reusable, patient safe recording, retrieval, exchange and  
archiving in mind.
A complete new set of scopes that need explicit requirements.

- Patterns are to be re-used and aggregated in other archetypes or  
templates.
Question: What are the rules to be applied to make that decision?

- A pattern will need a new specialization only when new things have  
to be added to the original pattern.
Question: What are the rules for to decide when  to specialize or when  
to add a new item to the original archetype and create a new version?

- What patterns do we have to have in order to be able to document  
what we need to document?
Will we find the answer when we look at the language aspects of what  
we document?

- Some Archetypes document complex notions.
For example: the Barletts Index.
It is  a collection of Observations about a patient system.
Each of these observations can be recorded using a documentation  
pattern.
The aggregation of observations is expressed as a number using an  
algorithm.
This aggregation is named the Bartletts Index.

All of the observations can be documented using separate archetypes  
using semi-quantitate patterns.
The algorithm can be documented in whatever format.
The result is documented using a semi-quantitative pattern,
either on its own as the professional opinion of the healthcare  
provider,
or as the result of the application of the algorithm, as substitute of  
the healthcare providers subjective estimation.

So the Bartletts Index can be a subjective statement of the class of  
Evaluation Archetypes based on Observations,
or the a subjective statement (Evaluation) by a healthcare provider  
without any reference to feeding observations,

What will we do when new observation elements are added to the  
Bartletts Index?
What will we do when a new algorithm is used to do the calculations?

Is this line of reasoning not leading to the following statements:
Observations are observations and end  up in Observation Archetypes  
and are recorded in the EHR, as such.
The Bartlett Index is a derivative that either is an Evaluation of  
Risk expressed as the ARchetype Index as perceived by the documenting  
healthcare provider,
or, the Bartletts Index is a formalism (algorithm) applied to a set of  
documented Observations leading to a risk index that has to be  
documented as an Evaluation.

I might even argue that the Bartletts Index is an agreed Common  
Template to express risk for the new born, that could change over time  
as it is the result of present opinions that can change.
This means that there are two versions of the Bartlett Index that  
express the same notion.
One is the professional opinion of the risk for the newborn by the  
healthcare provider is a certain number.
And that the risk is calculated by a specified algorithm using a  
defined set of observations.

Question: Is the Bartlett Index an Observation or an Evaluation?
Question: Are there two kinds of Indexes?
Question: Is the Bartlett Index an Archetype or Template?

Or more general:
Are Archetype about recording patterns?
Are Templates about context (location, time and culture) dependent  
collection of constituting archetypes?

Gerard













On 14, Jun, 2008, at 15:55 , Thilo Schuler wrote:

> Looking at the openEHR archetype repository, there is a generic lab
> archetype and several specialiced ones based on it. However, it seems
> to me that the specialisations were done mainly to create "battery"
> type lab results structures (e.g. laboratory-liver_function) I think
> keeping the lab archetype to one analyte and aggregating them in a
> template would be cleaner and better from a query perspective.
> Specialisations of the generic lab archetype should only be used to
> add a field that is missing for an unkonventinal lab test.
>
> What do you think?
>



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080614/1a2f5da0/attachment.html>

Archetypes - regex question

[Gerard Freriks]

William,

It is  potentially dangerous ground.
But ...

-  Archetypes express what can be documented about a specific topic.
Since such a 'Real Archetype' can or will consist of re-usable  
patterns, 'Real Archetypes'  consist many times of a collection of sub- 
archetypes that express recurring patterns of documentation.
In other words archetypes can and will be nested.
And there must be a way to specify what archetypes are part of the  
ensemble at what spots.

- It will create the problem for Archetype Governance.
We need to have rules and ways to manage and enforce them.
This needs a tool.
Ocean Informatics, for this purpose, has developed the Archetype  
Knowledge Manager.

Gerard


On 14, Jun, 2008, at 7:31 , Williamtfgoossen at cs.com wrote:

>
> We are getting into dangerous options here: include all and exclude  
> all in a time series where 'all' definitely changes both with  
> respect to revisions of the existing ones, deletions and new to be  
> added might lead to inconsistent calls to archetypes over time.
>
> I believe such constraining should not take place on the archetype  
> over archetype level, but at the (OpenEHR) template level. In here  
> you can be explicit in what is to be included or excluded.
>



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080614/8845ef4a/attachment.html>

Decision Support was: MIE-2008

[Gerard Freriks]

Hi,

The way I like to think about it is that there is a generic archetype  
for lab-tests as a recurring 'pattern'.
Each individual lab test procedure is a code from a general coding  
system.
The way Lab-test are reported (quantitative data, in what units of  
measurement, precision, normal value ranges, semi quantitative data,  
in what ordinal scale ,etc, etc) will be 'codes' as well, but this  
time from the Laboratory Resource Description System.

The 'patterns' will probably be a special type of Archetype that is of  
the cluster nature.
Batteries have  Template nature.

Gerard



On 13, Jun, 2008, at 6:11 , Hugh Leslie wrote:

> Hi Daniel
>
> I was just using that as an example where its not always useful to  
> code everything.  I certainly wasn't trying to say that its not  
> useful to code anything and the example that you give is where it is  
> useful to code.  I was just pushing back against those that want to  
> code everything as I believe that we need to code those things that  
> make sense.
>
> In terms of battery archetypes, thats another problem because  
> batterys tend to vary between labs (certainly here in Australia  
> anyway.)  I would expect that it might be templates that solve this  
> problem with the archetype providing something more generic.  Coding  
> of the analytes would then make sense so that you can compare  
> different result sets.  This could be also solved by producing  
> archetypes for each analyte and then reusing them for different  
> batteries.  This would then mean that P-ALAT is the same archetype  
> where ever it is used.  Personally, I think the coded solution is  
> better here as we would have fewer archetypes to manage.
>
> regards Hugh



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080613/37cb8174/attachment.html>

Decision Support was: MIE-2008

[Gerard Freriks]

Dear  Daniel,

yes, I said that the grey zone is a relic of the past,
It is there and we have to deal with it.
But that is not to say that it must stay the same.

To my mind we have to be aware that when dealing with semantics and IT  
we must stay close to the eons proven way to do things.
For eons we have had as semantic ingredients:
- a list of words (nouns and verbs) plus modifiers (adverbs,  
adjectives): dictionary/vocabulary
- a syntaxis/grammar
- ways to define what makes sense.

The list of words/dictionary/vocabulary defined the concepts building  
block to be used in grammar.
Using words and grammar we could produce sentences and express what we  
had to express.
But we could produce sensical and non-sensical combinations of words  
and grammar in sentences.
Therefor we had ways to select and use only the sensical sentences.  
And these are archetypes and templates.
Archetypes and templates -in addition- provide the patterns (types of  
sentences) that can be used in healthcare to document observations,  
evaluations, instructions, and actions.

We must think very carefully whether it is wise to have two grammars  
at the same time.
Archetypes and templates have on one hand the role of grammar and the  
pattern used for documenting.
What is a compelling reason to combine the role of a code-list with  
that of grammar in SNOMED?
Does SNOMED have a rich enough grammar?
As rich as archetypes and templates allow?
Does it has a way to deal with patterns?

Isn't it a solution for the grey zone problem to accept that from now  
on we use SNOMED as a code list / vocabulary, that eventually helps us  
reasoning because of the ontological features?
And that archetypes and templates are the grammar and the expression  
patterns?
Coding systems are a fact of life.
Archetypes and templates are a fact of life.
Both need a natural role.

Isn't this suggestion the most practical way to deal with the grey  
zone in the future?

Gerard

On Jun 10, 2008, at 9:55 PM, Daniel Karlsson wrote:

> I didn't say that the grey zone is a relic of the past but, quite
> differently, a fact we need to acknowledge and relate to. The main
> reason: terminologies are not just merely dictionaries but make
> assumptions of semantics that interact with assumptions of semantics
> made in archetypes. Also, in terminological languages, representations
> of the semantics may be processed formally.



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080611/da7e5c9f/attachment.html>

Decision Support was: MIE-2008

[Gerard Freriks]

leslie,

I agree with the statement below.

Gerard

On Jun 10, 2008, at 10:06 AM, Hugh Leslie wrote:

> openEHR needs SNOMED and I believe that SNOMED needs archetypes.   
> The decision will be where archetypes and SNOMED should begin and  
> end and I think there will be a lot of debate in the next year or so!



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080610/7e3ed64c/attachment.html>

Decision Support was: MIE-2008

[Gerard Freriks]

Dear colleague,

I agree with you that the grey zone is a relic from the past we have  
to deal with.
Never the less, I want to argue that we have to reduce this grey-zone.
By means of my suggestion to do post-coordination as much as possible  
in the archetype.

The main reason is:
- In language post coordination is done in the syntaxis and not in the  
dictionary.

Gerard

On Jun 10, 2008, at 9:37 AM, Daniel Karlsson wrote:

> Realizing that the current Snomed CT Concept Model is not enough  
> (today,
> unfortunately by far) and that the tools for supporting constrained
> post-coordination mainly are lacking, at least Snomed CT provides  
> *some*
> constraints on semantics in areas where openEHR provides none. Also,  
> the
> suggestion by David Markwell, I believe, is to represent semantics in
> Snomed space *as well as* in the archetype space.
>
> Also, I firmly believe that the "grey zone" will always exist as it is
> the result of the concurrent use of two different models of semantics.
> Thus, the boundary problem will not be "solved", rather we will have  
> to
> develop methods that makes the "grey zone" related problems less
> harmful.
>
> Regards,
> Daniel



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080610/31d12655/attachment.html>

Decision Support was: MIE-2008

[Gerard Freriks]

Ian,

I agree.
But my wished outcome is clear.

And of course we have to deal with the past.
But the sooner we, ...

Gerard

On Jun 5, 2008, at 12:48 AM, Ian McNicoll wrote:

> Hi Gerard,
>
> I agree with most of your comments and in principle that  "most
> post-coordination (using modifiers in Snomed-space instead of
> Archetype/Template space) must end", this amounts to heresy in a UK
> context and I think we should be prepared to regard David Markwell's
> Grey Zone as a contested area for some time. I think we could waste a
> lot of energy in trying to reduce the grey zone and might be better
> served by allowing dual-representation in both openEHR paths and
> Snomed post-coordination, and concentrating our efforts on the clearer
> areaswhere one approach is obviously better than the other. I would
> rather present Snomed-openEHR as the productive marriage of 2 noble
> families, whose sum is greater than the parts, whilst accepting that
> there will remain on-going jockeying for position in the 'border
> lands'.
>
> Ian (joyfully mixing his metaphors)



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080605/38e85b5f/attachment.html>

openEHR Querying specifications

[Gerard Freriks]

I must disappoint you:

Dutch: Revisie, versie.

Gerard


On Jun 5, 2008, at 12:36 AM, Ian McNicoll wrote:

>
> BTW  What would be the equivalents in Dutch for Revision and Version?



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080605/ca46bf5d/attachment.html>

openEHR Querying specifications

[Gerard Freriks]

Dear all,

The text below by Thomas warrants a conclusion:
- openEHR needs a (place in a) document that defines the correct  
wording and meaning of:
version and revision.

To my mind these words are to much similar and can generate confusions.
Alternatives:
Package (new Archetype that breaks the previous package archetype)  
plus conversion script from the Old to the New Archetype)
Version (new Archetype as the result of some editorial changes, only,  
not breaking the previous version)


Gerard

On Jun 4, 2008, at 10:23 AM, Thomas Beale wrote:

> The result of this is that new _versions_ of officially released
> archetypes should be very low in number and should always have a  
> formal
> definition of how to migrate data created using an older version.
>
> The confusing factor that people are seeing now is that due to the
> current tooling, most archetype authors are creating new 'versions'  
> when
> in fact the changes are only new revisions



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080604/4100af17/attachment.html>

Decision Support was: MIE-2008

[Gerard Freriks]

Hi,

Free text versus structured data and information debate:
- Like Ian said: Archetypes and templates take away problems from the  
IT-domain and leave them for those in healthcare.
When those in health need, want decision support they will have to use  
more structured info.
In the end they will solve their own problems.

- We, in the archetype world, will have to show the way.
Timo's thoughts are providing ways to think.
Archetypes used must be able to serve many purposes:
recording, retrieval, exchange, archiving and re-use for among others  
decision support.

- The boundary problem has to be solved.
Davids 'grey zone' must be reduced to a manageable small zone.
We can not change the past and must find ways to deal with pre- 
historic (pre-archetype) data.
In order to solve it we must look forward and reduce the 'grey zone'  
by acknowledging that most post-coordination (using modifiers in  
Snomed-space instead of Archetype/Template space) must end.

Gerard


On Jun 3, 2008, at 7:43 AM, Sam Heard wrote:

> Terminology
> A final part of the equation is the area that David Markwell has  
> been working on in the NHS in the UK. He is investigating how to  
> generate computable terminology code phrases from an archetype: that  
> is, how to post-coordinate information captured in an archetype for  
> inferencing in the terminology space. This has benefit in linking  
> with the pre-archetype data and may allow complex research to be  
> undertaken in the future using ontological tools and engines.
>
> So we need to keep the balance between freedom and structure,  
> recognising (as Ian McNicoll says) that good archetypes take the  
> problem out of the technical space to where it becomes a human (and  
> potentially soluble) issue.
>
> Cheers, Sam



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080603/d583d302/attachment.html>

XML Schema for the openEHR Demographics package?

[Gerard Freriks]

HI,

It is optional
as I happen to remember.

So when there is an archtyped one, so the better.

Standards are conservative documents.

Gerard


On 21, Apr, 2008, at 17:30 , Erik Sundvall wrote:

> P.s. Whatever happened to the demographics package when running it
> through the CEN standardisation-process? A brief look at the
> EN13606-spec gives the impression that they have hardcoded a number of
> field into theit RM instead of using archetyping, is this correct? Why
> on earth...?
> It even looked like there are no places to add new archetyped
> structures (like ITEM_STRUCTURE) anywhere in the 13606 demographics
> package, is this correct?
> __________



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080421/e1838a99/attachment.html>

On Information and Interoperability

[Gerard Freriks]

Dear all,

The EHR is about documenting and archiving data and information  from  
a health/care process.
There are good well developed standards from the Documenters/archivers  
domain.
http://www.interpares.org/

Many requirements are defined that most messages do not address.
And most systems that rely on messages for communication do conform to  
the requirements from Interpares.
Requirements for messages that update data bases are never completely  
the same as those for ICT-systems that document data and information.
Data and information that is searchable, usable correctly  and safely  
after 20 years and surviving many changes in society and IT  
technologies.

Gerard




On 18, Apr, 2008, at 14:21 , Tim Cook wrote:

> I agree with your format vs. design comments there.  But, your  
> examples
> lead me to believe that you are still focusing on sending messages  
> with
> limited context and have not considered implications regarding storage
> and retrieval of healthcare information for decision support, public
> health analysis, etc.



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080418/52856012/attachment.html>

Archetype documentation using XML + XSLT

[Gerard Freriks]

The crux might be in the text in red.

Everything can be made to work.
A floating boat made out of match stick. Yes it is possible,
but not the bet engineering choice.
Perhaps XML is not the best choice in all circumstances.

What about ASN.1 isn't that a good alternative?
How about the tools?
Not as ubiquitous as those for XML.

Gerard

On 17, Apr, 2008, at 17:29 , Adam Flinton wrote:

>> There are many better ways to represent data for large-scale
>> deployments than XML (even the dADL syntax from ADL does 100%  
>> better in space,
>> and represents all object-oriented constructs unambiguously).
>>
> You have got to be kidding me on this one.
>
> Having done XML messaging in very large retail systems (major
> supermarket chains in the EU & US), mobile phone systems, home
> office/criminal justice system & now the CFHyou simply have got to
> be kidding.
>
> umm...where to even startoh yes how about...



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080417/7c9de242/attachment.html>

openEHR vs MDA/MDD & DSLs

[Gerard Freriks]

Dear Thilo,

When using tools based on a model.
when systems based on an other model,
are capable to define what gets stored, retrieved, presented and  
exchanged without writing code, software or concerting databases,
then I call this MDA, MDD for quite some time.

In openEHR ones can see what others are dreaming of.


Gerard

On 11, Apr, 2008, at 23:15 , Thilo Schuler wrote:

> Hi all, just wanna share this:
>
> For many of you this might not be something new, but today I
> consciously noticed to many analogies between the Model Driven
> Architecture (MDA) or Model Driven Development (MDD)  including the
> trendy Domain Specific Languages (DSL) with openEHR's two model
> approach (see attached png from
> http://www.omg.org/cgi-bin/apps/doc?omg/03-06-01.pdf ) Obviously the
> reasons are partly different (plattform independant code vs semantic
> interoperability - although the openEHR RM can also be implemented on
> all plattforms) but especially DSLs try to abstract domain models from
> technical domain.
>
> PIM Metamodel  => AOM (while ADL ist a textual DSL for it!)
> PIM => Archetypes and Templates
> PSM Metamodel => openEHR Reference Model
> PSM => Reference model instances.
>
> Cheers, Thilo



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080412/21396f73/attachment.html>

Security & Privacy with openEHR

[Gerard Freriks]

Dear colleague,

In Europe there is a European Directive (law) on privacy.

The European standard for the EHR (CEN/tc251 EN13606 and also an ISO  
standard by now) has incorporated several other European and ISO  
standards:
- ISO 18308: requirements for EHR architectures
- ISO 22600 Privilege Management and Access Control
- CEN EN 13606 part 4

It is for these reasons that European based EHR standards are unique  
because Patient Safety and Privacy are part of the design requirements  
from the start.

For more information search the CEN and ISO standardization  
organisation websites.
To few people from the USA do that.

Gerard Freriks


On 14, Mar, 2008, at 18:52 , Kudakwashe Dube wrote:

> Hi All,
>
> I'm just beginning a research project on
> security/privacy/confidentiality in EHRs. I will greatly appreciate  
> any
> pointers to any material on this topic, especially with respect to
> openEHR.
>
> I've just noted that in the US, HIPAA is driving
> security/privacy/confidentiality implementations in existing EHR  
> systems
> and it seems its is turning out to be a policy/framework-level  
> security
> standard for EHRs in the US that does not prescribe implementation
> issues. I am not sure whether or not EHR standards that incorporate
> HIPAA compliance have emerged yet.
>
> In the EU region, the situation seems different in the absence of
> HIPAA-type punitive legislation for enforcing healthcare information
> security and privacy. A number of EHR standards generally incorporate
> security and privacy considerations. I am not sure whether there are  
> any
> security and privacy compliance requirements spec standards and
> implementation (incl. openEHR) in the EU region. I will appreciate any
> pointer to material in this regard.
>
> Thank you in advance
>
> Regards
> 
> Kuda



--  --
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer at luna.nl


Those who would give up essential Liberty, to purchase a little  
temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov  
1755





-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080314/b94f08d3/attachment.html>