Units, Quantities, etc

[Stef Verlinden]

Verstuurd vanaf mijn iPhone

Op 18 mrt. 2012 om 15:15 heeft Thomas Beale  het volgende geschreven:

> I still think Quantities should be computable as such - if we don't know how 
> many mcg of substance 3 puffs is, we can't compute with it.

Although i tend to agree with you, this won't work because then you assume that 
we're talking about the absolute truth. The absolute truth only exist when 
you're talking, for instance, about astronomics. In medicine you can't say 25 
ml of alcohol is lethal. You can only say something like: 25 ml of alcohol is 
lethal in an adult man of 80 kg. And only when he doesn't drink more than 15 
unit alcohol ? week. When he drinks more then The lethal dose is higher. For ? 
roman of the same weight who drinks < 15 units ? week, the lethal dose is 
lower. 

My point is that an absolute quantity alone doesn't meander much. At The other 
hand, we know empirically that if someone has smoked 15 pack years he's at 
serious risk. 

Then about puffs. I' m almost sure that you can translate ? puff info a volume. 
If i remember it correctly 40 drops is 1 ml. So the same should go for puffs. 

Cheers, Stef

13606 revisited - list proposal

[Stef Verlinden]

I asume there is no subscription fee for openEHR members.

Cheers,

Stef


Op 15 dec. 2011, om 11:33 heeft Gerard Freriks het volgende geschreven:

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

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

Fwd: [openEHR-announce] CIMI group goes with openEHR archetypes & UML profile

[Stef Verlinden]

Congratulations to all who made this possible and to ourselves

This is a crucial 'breaktrough' which will pave the way towards future proof 
health records which will be widely accepted and used.


Cheers,


Stef

Begin doorgestuurd bericht:

> Van: Thomas Beale 
> Onderwerp: [openEHR-announce] CIMI group goes with openEHR archetypes & UML 
> profile
> Datum: 14 december 2011 10:38:14 GMT+01:00
> Aan: openehr-announce 
> 
> [press release from the CIMI group]
> The Clinical Information Modeling Initiative is an international 
> collaboration that is dedicated to providing a common format for detailed 
> specifications for the representation of health information content so that 
> semantically interoperable information may be created and shared in health 
> records, messages and documents. CIMI has been holding meetings in various 
> locations around the world since July, 2011. All funding and resources for 
> these meetings have been provided by the participants. At its most recent 
> meeting in London, 29 November - 1 December 2011, the group agreed on the 
> following principles and approach. 
> 
> Principles
> 
> 1. CIMI specifications will be freely available to all. The initial use cases 
> will focus on the requirements of organisations involved in providing, 
> funding, monitoring or governing healthcare and to providers of healthcare IT 
> and healthcare IT standards as well as to national eHealth programs, 
> professional organisations, health providers and clinical system developers.
> 
> 2. CIMI is committed to making these specifications available in a number of 
> formats, beginning with the Archetype Definition Language (ADL) from the 
> openEHR Foundation (ISO 13606.2) and the Unified Modeling Language (UML) from 
> the Object Management Group (OMG) with the intent that the users of these 
> specifications can convert them into their local formats.
> 
> 3. CIMI is committed to transparency in its work product and process.
> 
> Approach
> 
> ADL 1.5 will be the initial formalism for representing clinical models in the 
> repository.
> CIMI will use the openEHR constraint model (Archetype Object Model:AOM).
> Modifications will be required and will be delivered by CIMI members on a 
> frequent basis.
> A set of UML stereotypes, XMI specifications and transformations will be 
> concurrently developed using UML 2.0 and OCL as the constraint language.
> A Work Plan for how the AOM and target reference models will be maintained 
> and updated will be developed and approved by the end of January 2012.
>  Lessons learned from the development and implementation of the HL7 Clinical 
> Statement Pattern and HL7 RIM as well as from the Entry models of 13606, 
> openEHR and the SMART (Substitutable Medical Apps, Reusable Technologies) 
> initiative will inform baseline inputs into this process.
> A plan for establishing a repository to maintain these models will continue 
> to be developed by the group at its meeting in January.
> Representatives from the following organizations participated in the 
> construction of this statement of principles and plan
> 
> B2i Healthcare www.B2international.com 
> Cambio Healthcare Systems www.cambio.se 
> Canada Health Infoway/Inforoute Sant? Canada www.infoway-inforoute.ca 
> CDISC www.cdisc.org 
> Electronic Record Services www.e-recordservices.eu 
> EN 13606 Association www.en13606.org  
> GE Healthcare www.gehealthcare.com 
> HL7 www.hl7.org 
> IHTSDO www.ihtsdo.org 
> Intermountain Healthcare www.ihc.com  
> JP Systems www.jpsys.com 
> Kaiser Permanente www.kp.org 
> Mayo Clinic www.mayoclinic.com 
> MOH Holdings Singapore www.moh.com.sg 
> National Institutes of Health (USA) www.nih.gov 
> NHS Connecting for Health www.connectingforhealth.nhs.uk 
> Ocean Informatics www.oceaninformatics.com 
> openEHR Foundation www.openehr.org 
> Results4Care www.results4care.nl 
> SMART www.smartplatforms.org 
> South Korea Yonsei University www.yonsei.ac.kr/eng 
> Tolven www.tolven.org 
> Veterans Health Administration (USA) www.va.gov/health 
> Further Information
> 
> In the future CIMI will provide information publicly on the Internet. For 
> immediate further information, contact Stan Huff (stan.huff at imail.org)
> 
> 
> ___
> openEHR-announce mailing list
> openEHR-announce at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-announce

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

Could YAML replace dADL as human readable AOM serialization format?

[Stef Verlinden]

+1

Cheers,

Stef


Op 6 dec. 2011, om 12:44 heeft Seref Arikan het volgende geschreven:

> 
> Please do not get me wrong, all the discussion we are having here is useful, 
> it is just that in my humble opinion, some discussions are more useful than 
> others if this standard into which I am heavily investing is to go forward. 

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

EN/ISO 13606 & openEHR - harmonisation possibilities

[Stef Verlinden]

Great initiative. Let's go for it. Even though I agree with your previous 
remarks that this probably won't provide a long term solution, IMHO it's 
absolutely necessary in order to secure short term progress.

Maybe a dumb question, but is there a way we can involve people form other 
standard initiatives (DCM, HL7) in order to speed up harmonisation. More 
specific: is there a mutual interest for all of us to invest in this. 

Cheers,

Stef

Op 9 sep 2011, om 14:24 heeft Thomas Beale het volgende geschreven:

> 
> As you may have noticed, the new release of the ADL Workbench enables 
> exploration of multiple reference models and their classes. Although the 
> 13606 schema is not yet complete (in particular the data types require work), 
> it is now possible to see the differences and similarities of the 13606 and 
> openEHR reference models. Similarly, archetypes based on both reference 
> models can be viewed, validated and compared. 
> 
> I see various possibilities:
> convergence of 13606 and openEHR onto one reference model. The opportunity to 
> do this is coming up in May 2012, where 13606-1 and 13606-2 reach their 3 
> year review point, at which ISO has to decide to either retire them or 
> continue their use, depending on their use in industry. I don't know what use 
> in industry they have to date, but let's assume the decision is made to 
> continue - it is clear that changes could be made. Implementers of both 
> openEHR and 13606 have now had some 3 years to discover real problems and 
> deficiencies. In openEHR there are around 150 Problem Reports and Change 
> Requests generated over this time; clearly some of these would apply equally 
> to 13606. Some possible changes:
> it is now possible to see how 13606 and openEHR could be merged into one 
> reference model at the Entry level, e.g. with changes like:
> openEHR has richer 'design-based' Entry types like Observation, Instruction 
> and Action, but also a generic type called Integration_entry, which nearly a 
> mirror image of the EN13606 ENTRY. A future standard could support all of 
> these types, with the users choosing which ones best supported their data.
> openEHR's data structures (ITEM_STRUCTURE, ITEM_TREE, ITEM_TABLE) etc may be 
> able to be retired in lieu of the only simpler CLUSTER/ELEMENT structure in 
> use by both standards, and a 'structure marker' as used by 13606 - this would 
> further ease merging of the reference models.
> a common data types model could be found. At the moment, openEHR's data types 
> work very well and have been shaped by archetyping as well as normal software 
> considerations. For 13606, in theory the ISO 21090 data types are supposed to 
> be used. In their current state, they cannot be, and are both completely 
> normalised and optimised for HL7v3 use, as well as suffering from key 
> modelling problems. It has been stated that an ISO 21090 'profile' will be 
> developed for 13606, although this has not yet been done. In my view, the HL7 
> 'profiling' process is almost unworkable, and I think a completely different 
> set of data types is needed for 13606 - a far simpler set, e.g. based on a 
> simplified version of openEHR, or Grahame Grieve's Resources for Health data 
> types (which include   both openEHR and HL7 influences, as well as 
> using proper object modelling).
> a few useful Change Requests have been made based on CDA. Once these are 
> done, the merged RM would be a superset of all models in use today, with the 
> added value of being more rigorously defined and therefore usable for 
> tool-based code generation, data transformation and the like.
> adoption of ADL/AOM 1.5 as a new 13606 part 2. Although it seems as if ADL 
> 1.5 is taking a long time (it is ;-) it is being continuously tested in real 
> software on the way, so that what emerges will be something close to a 
> 'stable' standard (openEHR might decide to give it DSTU status from the 
> outset for example) rather than an untested set of proposals. It is 
> backwardly compatible with ADL 1.4, while fixing all the main problems and 
> limits of 1.4. It includes many (in fact almost only) features proposed by 
> people working with real archetypes in real environments, so I think it is 
> safe to say that the 40 or so changes (most very small) really reflect the 
> last 4-5 years' industry validation rather than any kind of theorising. If 
> ADL/AOM 1.5 were to become the next version of 13606-2, then we can 
> contemplate:
> shared tooling: doing this would mean that all 13606 efforts can use the 
> openEHR tooling, which is growing by the day, and that people working with 
> openEHR can use tooling that is currently 13606 ADL specific.
> shared archetypes: if the reference models were merged then '13606 
> archetypes' and 'openEHR archetypes' are just the same thing - it is just a 
> question of different parts of the same reference model being archetyped.
> How could we go about this work?
> we can all

openEHR Transition: two procedural and one licensing question

[Stef Verlinden]

Op 7 sep 2011, om 09:55 heeft Erik Sundvall het volgende geschreven:

> Do read that wikipage and follow the links there to the mail
> discussions. What is it that you think is missing or unclear in the
> arguments against SA?



That they're hidden in a lot of text form which one has to follow through 
hyperlinks and read even more text.

You stated somewhere - correctly - that companies want to avoid risk, similarly 
decision makers want to avoid reading through lengthy discussion (from which 
they have to draw there own conclusions:-) )


If I understand you correctly your main argument is that:

the share alike (SA) requirement will create a risk for lengthy juridical 
procedures - in every country they operate - for companies  who include openEHR 
archetypes or derivatives thereof in their systems. Since companies avoid risk, 
they  will choose other solutions without an SA requirement.

The reason for this is that it's not clear what SA exactly means. For instance 
in the context of building archetype-based GUI- stubs, forms etc. in 
proprietary systems. As a consequence it could be possible that companies are 
forced - unwillingly - to open up the source of their proprietary systems. It 
will take years and many court cases, in different countries, to sort this out. 
Until then (the large) companies will stay away from openEHR.

This problem can be avoided completely by dropping the SA requirement.


So I guess the first question is: who has a solid argument against Erik's 
argument.

The second question is: what are the exact benefits of the SA requirement and 
are they worth the risk of companies not using openEHR at all (presuming that's 
a real risk).


Cheers,

Stef



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

openEHR Transition: two procedural and one licensing question

[Stef Verlinden]

Hi Eric,

Good that you bring up the SA + or - discussion again. In order to make the 
best decision can you please provide us with these arguments and, if possible, 
with the names of those companies/organisations.

Cheers,

Stef


Op 6 sep 2011, om 16:51 heeft Erik Sundvall het volgende geschreven:

>  I have heard serious arguments in more than
> one country where companies/organisations are not wanting to use
> openEHR archetypes partly because of the SA licencing issue. 

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

Fwd: [openEHR-announce] openEHR Transition Announcement

[Stef Verlinden]

Very good news indeed. This is exactly what is needed to bring openEHR to where 
it belongs, at the center of the healthcare.

Just out of curiosity, who are these Associates, will they raise sufficient 
money and how long will it take before these become plans effective. The sooner 
the better is my idea:-)

Cheers,

Stef

Begin doorgestuurd bericht:

> Van: Thomas Beale 
> Datum: 5 september 2011 03:00:45 GMT+02:00
> Aan: openehr-announce 
> Onderwerp: [openEHR-announce] openEHR Transition Announcement
> 
> 
> Dear All,
> 
> I am writing on behalf of the new Transitional Board of openEHR to share our 
> plans to take openEHR to a new level of operations; a new structure, business 
> model and governance. Our vision is the creation of a thriving community that 
> works collaboratively to benefit humanity through efficient and effective 
> electronic health records (EHRs) that support the highest quality health care 
> for the least effort.  
> 
> Until now, the openEHR Foundation has functioned as an owner of intellectual 
> property, governed by University College London and Ocean Informatics, with 
> board members Prof David Ingram (UCL), Prof Dipak Kalra (UCL) and Dr Sam 
> Heard (Ocean).
> 
> 
> With the support of the considerable community of Members and via engagement 
> of a new category of sponsoring organisational Member known as ?Associates? - 
> Companies, Universities and Governments - the Transitional Board proposes a 
> number of changes:
> 
> The openEHR Foundation becomes an operational non-profit organisation with 
> paid key staff and resources;
> The Board (of governance) of the Foundation is extended to up to 10 people 
> with a shift to election by the openEHR Associates;
> Members who participate are recognised by their peers, may take on 
> decision-making roles, and have the right to commit changes to the key 
> development assets of the Foundation.
> The Members will participate individually and, through qualification by peer 
> recognition, will control the development within the three Programmes that 
> are building the key assets:
> 
> The openEHR specifications of the logical health record and attendant 
> services as well as the methods for describing the content using archetypes 
> (Detailed Clinical Models) and templates; and
> The openEHR archetypes and templates to be used within systems and for 
> message content between systems to achieve interoperability; and
> The openEHR software projects, to provide open source development of tools to 
> support the uptake and use of the specifications and templates.
> A group of Members will be needed to bootstrap each of these programmes and 
> determine the working arrangements that are suitable to the products that 
> they are managing at the current stage of development.
> 
> The Associates will determine who governs the Foundation by nominating and 
> voting on new members of the Board. The Board will appoint key Operational 
> staff and will approve the leader of each of the Programmes. The Programme 
> Leaders will be appointed by Qualified Members working in that Programme, 
> subject to Board approval. We believe this will create the right balance 
> between the ?ground up? creation of openEHR through participation of Members 
> and ?top down? governance.
> 
> The first step is to share with you a white paper providing more detail on 
> the proposals and to ensure that the Members are reasonably satisfied that 
> this is the right direction to head. 
> Some key activities have been proceeding in the background and are reaching a 
> point of maturity. It has taken us some time to gather more clinical 
> champions in this endeavour and companies that can use and work with the 
> tools in their early stages of development. It has also taken quite some time 
> for Thomas Beale to work out how to provide a seamless pathway between 
> definition of archetypes, specialisation of archetypes to ensure development 
> scalability, to meet jurisdictional requirements, and templates that allow 
> tailoring for actual use in specific settings. The result is ADL/AOM 1.5. He 
> has, as usual, been totally committed to this work and it is probably very 
> important for me to say, it is ?no mean feat?.
> 
> There is a lot to do. Most important are:
> 
> Begin to showcase development teams and software using openEHR successfully 
> in clinical settings;
> Finalise ADL/AOM 1.5, including its succinct XML expression, and integrate it 
> into existing and emerging tools;
> Update the openEHR reference model to version 1.1 bringing our collective 
> knowledge to bear on the new features and changes while ensuring backward 
> compatibility;
> Begin an open source software project for tools, web-based if possible, to 
> author archetypes, templates and terminology reference sets directly 
> interacting with the Clinical Knowledge Manager and equivalent repository and 
> review tools; and
> Establish a mechanism for Associates to formally endorse 

Multiple archetypes in a single concept as a way to create an archetype collaborative

[Stef Verlinden]

Just to add to this. Another great aspect of openEHR is the separation of the 
technical and medical (content) aspect. 

In the clinical knowlegde manager (which Thomas already referred to) clinicians 
can cooperate to create archetype without have to think about the technical 
aspects. As for the technical people: whatever the clinicians come up with, 
they don't have to change any code, unless it would require a change in the 
reference model, which is extremely rare.

Cheers,

Stef


Op 3 aug 2011, om 09:44 heeft Hugh Leslie het volgende geschreven:

> Hi Joaquin
> 
> Just to add another  view...
> 
> The issue of openMRS implementations having different representations of the 
> same thing is a common problem across clinical systems everywhere.  Its this 
> problem that is one of the things that we are trying to solve with 
> archetypes.  In general, what we find is that most clinical concept 
> representations in clinical systems are subsets (based on a use case) of a 
> fully specified concept.  What we try to do in the archetypes is produce 
> the fully specified concept and then constrain it for all the use cases.  The 
> different names that you see used for different concepts are not just 
> language dependent, but are also region and usage dependent.  This is also 
> usually a  matter of constraining the archetype or using a particular 
> terminology subset to represent the information.
> 
> What openEHR offers openMRS is a single way of representing clinical 
> information that becomes a logical record architecture.  If openMRS adopted 
> this approach, then any openMRS system could immediately share information 
> with any other even if the other system hadn't seen the information before.  
> It also means that the burden of developing high quality, clinician validated 
> information models is shifted away from the application developer to a global 
> or regional space.  This is going to become more and more critical, as we try 
> to capture more complex clinical information and compute on it as well as 
> share it.
> 
> regards Hugh
> 
> On 3/08/2011 3:29 AM, Blaya, Joaquin Andres wrote:
>> 
>> Hi,
>> Apologies in advance if this is the incorrect email list for this topic, but 
>> I thought it was the most relevant.
>> 
>> I'm a member of OpenMRS and there we are discussion a way to have users 
>> share the concepts (a limited form of an archetype) created in their 
>> systems. This means that for a single concept you could have many concepts 
>> from different implementations. This could be because of language or because 
>> different words refer to the same concept. For example, Gender in the US 
>> might be Sex in another country and Sexo in spanish.
>> 
>> I would like to see if OpenEHR has solved this problem so that perhaps 
>> OpenMRS could begin to use archetypes.
>> 
>> Thanks
>> 
>> Joaquin
>> 
>> om 
> 
> ___
> 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: 

Representing binary values with DV_BOOLEAN

[Stef Verlinden]

And it's to simplistic too. In that case one also would like to know allergic 
to which specific type(s) and/or components of penicillin. In that case I also 
would like to know how that was tested, when and who did that etc., etc.

So I guess what's I'm trying to say is: What's the value of such forms and 
should we discuss this at this level? I guess that doctors always will keep 
using local forms for all sorts of purposes and at their own responsibility but 
I don't think we should try to standardize these form as well.

I we're able to record the symptoms/abnormalities/functions found or exluded, 
by whom using which method it's up to the person who has access to that data 
how to interpret it and to evaluate if he/she can draw a conclusion based on 
his/ her standards.

Like I said earlier an diagnose RA from hospital A can be a different disease 
from the one meant by the diagnose RA from hospital B and unless I have access 
to the underlying data I can't and won't use the the diagnose.


Cheers,

Stef


Op 10 feb 2011, om 11:47 heeft Ricardo Correia het volgende geschreven:

> Of course, this would for sure have bad implications regarding the size of 
> forms and time to fill them

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

Representing binary values with DV_BOOLEAN

[Stef Verlinden]

To make thing even more complicated (we discussed this already some years ago) 
the question should be: Does the patient have diabetes according to the 
definition used commonly in this practice/ hospital/ county/ country/ part of 
the world.

Don't remember it exactly but back then I could easily find more than 4 
different definitions of the disease/ syndrome called RA. 

So maybe you search for DM patient should be 'diabetes Y/N' but 'symptom X 
present' AND 'blood glucose > Y' etc., etc. so that you find only those DM 
patients that comply to your locally used definition of DM.

This is also one of the bottle necks, would I blindly treat a DM patient who's 
diagnosed according to a different definition/ standard then I'm using? 
Probably not. So whether it's a boolean or a coded_text the phrase DM Y 
doesn't mean much, unless I know the rest of the story as well. (I make the 
contrast a bit 'black and white' for discussion purposes)

Cheers,

Stef




Op 9 feb 2011, om 19:03 heeft Ian McNicoll het volgende geschreven:

> Interesting discussion.
> 
> The big problem with DV_BOOLEAN is that it subverts the standard
> 'clinical statement model' used in current health informatics.
> 
> e.g The patient has diabetes (DV_CODED_TEXT) ) vs. Does the patient
> have diabetes ? Y/N (DV_BOOLEAN).
> 
> This of course complicates looking for patient with diabetes, sine we
> now have to run 2 different searches and the boolean variation may not
> be able to take advantage of the inferencing in the terminology i.e
> sub-types of diabetes.
> 
> The other problem is when desiging archetypes, what may seem like a
> simple boolean, turns out to be a lot more complex when other clinical
> groups are involved.
> 
> To take Derek's consent example. On the face of it, Consent Y/N seems
> like a boolean but if you look at Snomed, there are at least 30 terms
> below Consent status e.g. self consent, verbal consent for
> examination. I found similar issues when modelling other clinical
> findings
> 
> Blood in the urine Y/N in some data capture vs. Ordinal scales +,++
> etc etc in others.
> 
> This starts to become very important when interoperating with other
> clinical groups.
> 
> Null values are useful but often match poorly to the clinical terms
> for a particular use case.
> 
> Negated questions are a further problem - what does Diabetes (no) mean
> - are we asserting that the patient does not have diabetes or is the
> negation just a way of ensuring that the question has actually been
> asked. We do not normally capture negations in 'clinical statement'
> stylwdata capture.
> 
> So !!!
> 
> Clinical questions are always going to be with us, and are certainly
> easier to use when generating GUI but they have major issues with
> interoperability and extensibility. My own ompinion is that we need to
> look at some sort of clinical variation on DV_BOOLEAN, as Koray
> suggested that allows the various True, False and null states to be
> mapped/bound to term based equivalents, as Koray has already
> suggested.
> 
> e.g.
> 
> Diabetes Y => Snomed Diabetes term
> Diabetes N => Exclusion of Diabetes (or perhaps just boolean N).
> 
> This would have the advantage of allowing alignment with clinical
> statements but make it easier for GUI designers to understand how to
> represent the questionairre.
> 
> 
> I very rarely now use DV_BOOLEAN when modelling but agree that using
> DV_TEXT/CODE_TEXT is a pain to map to a checkbox/radiobutton GUI.
> 
> Ian
> 
> Dr Ian McNicoll
> office +44 (0)1536 414994
> fax +44 (0)1536 516317
> mobile +44 (0)775 209 7859
> skype ianmcnicoll
> ian.mcnicoll at oceaninformatics.com
> 
> Clinical analyst, Ocean Informatics, UK
> openEHR Clinical Knowledge Editor www.openehr.org/knowledge
> Honorary Senior Research Associate, CHIME, UCL
> BCS Primary Health Care  www.phcsg.org
> 
> 
> 
> 
> On 9 February 2011 17:18, David Moner  wrote:
>> 
>> 
>> 2011/2/9 pablo pazos 
>>> 
>>> I mean: when there is no data, it is taken as false, but what happen if
>>> the person who do the questionnaire do not try to make this question false?
>> 
>> 
>> I do not agree with this. When there is no data, there is no data, neither
>> true nor false. And the null flavour gives us the reason for that case. I
>> think the DV_BOOLEAN is perfect as it is and if in some case it is not good
>> for your needs, then you should use a different data type (a coded text for
>> example).
>> 
>> 
>> --
>> David Moner Cano
>> Grupo de Inform?tica Biom?dica - IBIME
>> Instituto ITACA
>> http://www.ibime.upv.es
>> 
>> Universidad Polit?cnica de Valencia (UPV)
>> Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
>> Valencia ? 46022 (Espa?a)
>> 
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>> 
>> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technic

Joint HL7 RIMBAA / OpenEHR implementers list

[Stef Verlinden]

Dear Rene,

This is good news. Great blog too.

I really like the initiative to start a joint feasability project. I'm 
confident that there will be a outcome that will not only work for all parties 
involved but also creates synergy.

Is it an idea that based on the presumed positive outcome of this project we go 
back to IHTSDO with a renewed proposal? Don't know what the HL7 involvement is 
at this moment, but now is the time to convince IHTSDO that they should prepare 
for the standards of the future and use those as the basis for their 
developments


Cheers,

Stef


Op 25 jan 2011, om 09:25 heeft Rene Spronk (Ringholm) het volgende geschreven:

> During the HL7 WGM the HL7 RIMBAA group (software developers that use 
> the HL7 RIM for persistence and in memory processing) met with OpenEHR 
> implementers (mainly: representatives from Ocean Informatics).
> 
> We found we have a lot in common when it comes to architectural and 
> implementation approaches. See 
> http://wiki.hl7.org/index.php?title=RIMBAA_201103_Agenda for minutes of 
> that meeting (browse down a bot until you reach the minutes of the 
> Thursday meeting) , and 
> http://www.ringholm.com/column/HL7_openEHR_finally_cooperating.htm for a 
> related blogpost.
> 
> Representives of Ocean have indicated that they'll be present during the 
> next HL7 WGM in Orlando, so we'll be organizing this joint implementers 
> model again. We'd also like to invite any other implementations of 
> OpenEHR to this meeting.
> 
> "Reference Model" based software development - that's what we have in 
> common as implementer communities.
> 
> TTYL,
> 
> -Rene
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

ISO 21090

[Stef Verlinden]

Dear Grahame,


Op 23 nov 2010, om 14:24 heeft Grahame Grieve het volgende geschreven:

> It appears that Tom and I may jointly develop a variant
> of ISO 21090, that features the same basic semantic
> content, but in a format that is suitable for use in systems
> rather than for exchange. It will describe clearly how to
> interoperate using 21090, but will be suited for system/case
> design.

This is really great news. 

Still I think that the result of your joint effort should be adapted by 
representatives of the communities who are discussing on this list  (and 
preferably some others to) and if all agree on it bring it further into the 
formal standardization process. Maybe would coudl see it then as a WWTA (World 
Wide Technical Agreement). To answer you question, important technical agreed 
standards should still become formal standards because, at least here in 
Europe, they can be incorporated in laws. Informal standards or technical 
agreements can't. And that's an important issue when governments are going to 
make (or adapt) legislation about EHR's

I also wonder what the others think of this effort. People in Ed's group or the 
DCM people should possibly benefit from this as well or do they see that 
differently?


Cheers,

Stef

World Peace

[Stef Verlinden]

Dear all,

As Ed Hammond said it somewhere earlier in this discussion:  It's like World 
Peace - a great idea but probably not achievable.

I agree with Ed if we think along the line of ?one solution should fit all? and 
I also think that if we create different solutions for different purposes World 
Peace is achievable after all. Please let me explain.

The 21090 standard is a fact, is here to stay and is not going to change 
(soon). As William G. said it has been a tremendous accomplishment and Graham 
did a hell of job in finding consensus between all parties involved. Based on 
the reactions of some in this list and the fact the the majority of CEN and ISO 
voted for it, 21090 fits it?s current purpose which is:

?provides set of data type definitions for representing and exchanging basic 
concepts that are commonly encountered in healthcare environments in support of 
information exchange in the healthcare environment? 

The way I see it, the main point of discussion untill now is the question: 
exchange between who and/or what. This is also where the solution lies. 

Although it isn?t stated specifically the current use of the 21090 seems to be 
primarily at the level of functional interoperability (? the ability of two or 
more systems to exchange information (so that it is human readable by the 
receiver) (ISO/TR 20514:2005)). I?m sure it?s intended use is also at the level 
of (some) semantic interoperability but allow me to make this distinction to 
explain the need for different solutions. 

What Tom and many others on the list here are striving form is (let?s say an 
?advanced level? of) semantic interoperability (? the ability for information 
shared by systems to be understood at the level of formally defined domain 
concepts (so that information is computer processable by the receiving system) 
(ISO/TR 20514:2005)). 

With advanced I mean that systems can not only support but eventually take over 
certain critical functions in the medical process. This goes beyond the level 
of decision support. In in the (not so far) future also fully automated systems 
based on input from several parties will be created. For instance automated 
triage of after hours GP visits, assess whether someone can get a refill 
prescription, an agent that checks for medication interaction, automated 
screening for certain risk profiles, follow up of patients with a certain 
diseases, etc, etc.

Whether we like it or not, systems have to support and even take over some 
functions of healthcare providers in order to be able to provide sufficient 
care 10-15 years from now. If not for that reason alone,  this type of 
applications can (hopefully) help to improve the quality of healthcare.  For 
instance by making personalised medicine possible at a large scale.

These advanced systems are (potentially) going to decide on matters of life and 
death and  therefore they need to be reliable in that the outcome must be 
correct and similar in every system that uses the same standard(s). 

I fully agree with Tom?s remark that this requires an engineered standard 
instead of one that is the result of a political process (If you know the 
person who would travel on a plane built by 'democracy' rather than 
engineering, please introduce us... ))


So here?s my proposal

We leave the 21090 for what it is right now and focus on a datatype standard 
for semantic interoperable systems to be used in critical healthcare processes. 
This is a new and very specific scope which not only justifies but calls for a 
new standard. 

The thing we?re going to do differently is that for the standard creation 
process we?re - initially - going to bypass the political process. To do so, a 
small group of dedicated engineers (2-3 from all parties involved/ interested, 
is composed. Based on the reactions on this list it should be possible to get 
at least engineers of HL7, DCM,13606, and openEHR involved. Preferably this 
should be extended with engineers from IHTSDO, NHS, the Swedish implementation 
group and ?.? Lets say a maximum of 20 people. The goal  of this group is to 
create a datatype standard for semantic interoperable systems to be used in 
critical healthcare processes which addresses the following requirements:

- a set of clean, clear core data types 
- a set of wrapper types designed to use the core types, optimised for messaging
- other sets of wrapper types as needed, optimised for other specific purposes, 
e.g. storage or whatever

Also the standard should be modular in order to expand it quickly and easy in 
the future if new use cases would require that.

If all parties involved agree upon the end result, the standard will be brought 
to CEN/ISO to be included into the formal standardisation process. This of 
course would need some political work after all, since all CEN/ISO members 
would need to vote for this need standard in order to make it  official.

I?m very confident that if the standard is developed and agreed upon by

ISO 21090 data types too complex?

[Stef Verlinden]

Great, do you have a link where they can be found/seen.


Cheers,

Stef

Op 8 nov 2010, om 21:02 heeft Williamtfgoossen at cs.com het volgende 
geschreven:

> In a message dated 8-11-2010 15:38:26 W. Europe Standard Time, thomas.beale 
> at oceaninformatics.com writes: 
>> I have been asking HL7 since 2003 or so to show a clean model of any of the 
>> following in RIM or CDA structures:
>> 
>> 2 or 3 sample Apgar 
>> standard 3 sample GTT (glucose tolerance test) with patient state 
>> ICU vital sign time series
> 
> 
> Tom,
> 
> these are available since about that time in HL7 space. However, they where 
> not balloted yet. 
> 
> William
> 
> Met vriendelijke groet,
> 
> Results 4 Care b.v.
> 
> dr. William TF Goossen
> directeur
> 
> De Stinse 15
> 3823 VM Amersfoort
> email: wgoossen at results4care.nl 
> telefoon +31 (0)654614458
> 
> fax +31 (0)33 2570169
> Kamer van Koophandel nummer: 32133713   
> ___
> 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: 

ISO 21090 data types too complex?

[Stef Verlinden]

It looks like we're getting to the heart of the matter here.

What I really  would like to know from the others what their opinion's on these 
subjects are?

If it indeed turns out to be true that Tom don't understand how datatypes, RIM 
or data types are working, we, as the openEHR community, should ask him to shut 
up. If not we should find better ways to get the message across...


Cheers,

Stef

Op 7 nov 2010, om 12:12 heeft Grahame Grieve het volgende geschreven:

> hi Tom
> 

.

> 
>> The context specific stuff is specific to HL7 only. It just doesn't apply 
>> elsewhere.
> 
> not at all. And I'm surprised you still think this. HXIT is to do with 
> capturing
> and managing foreign data. As is some of the II stuff. It doesn't and won't
> arise in an EHR system for internal data, but it will for imported data. So
> where it does arise is not HL7 specific.
> 
> Flavors are a ISO 21090 thing. And optional - they aren't in the schema,
> for instance.
> 
> Update mode is transactional. Almost everybody will profile it out.
> 

..

> 
>> There is not a close correspondence between the 21090 idea of
>> ?ANY? and the typical Any/Object or other root class of most
>> object-oriented type systems ? this name clash would have to be resolved in 
>> some way;
> 
> It appears I will have to keep repeating this until I am blue in the face.
> It is not a name clash, nor does it (or should it) correspond to a root class
> in any other system - it is it's own class. The fact you think this indicates
> that you are totally confused as to what ISO 21090 is. (Hint: look at how you
> modeled your own data types...)
> 

...

> 
> 
>> The modelling style seems to follow the strange HL7 obsession
>> with non-object orientation, popularised in the RIM.
> 
> which indicates that you don't understand the RIM or the data types,
> and how they differ.
> 
> Grahame
> 
> ___
> 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: 

ISO 21090 data types too complex?

[Stef Verlinden]

Dear Ed,


Thanks for your clear and frank contribution to this discussion. Although I 
don't always agree with the boldness of Tom's remarks and I'm one of those 
people with 'little competence' (although I tent to think that I understand 
what is being engineered), I can understand his frustration as well. It's 
difficult if you try to reach something that you feel is being blocked just 
because people don't see what you're doing and as a result they choose 
somethings that looks sufficient today.

Looking through this frustration, wouldn't you agree that an ideal 
international standard on datatypes should be about
a set of clean, clear core data types 
a set of wrapper types designed to use the core types, optimised for messaging
other sets of wrapper types as needed, optimised for other specific purposes, 
e.g. storage or whatever
If no, how would your ideal standard look like?

If yes, how could we go about to establish this is the near future?


Cheers,

Stef

Op 7 nov 2010, om 01:33 heeft William E Hammond het volgende geschreven:

> Interesting comments.  It is interesting that the ISO standard was approved
> by HL7, CEN and ISO.
> As to why we fix the problems of ISO 21090 on HL7, someone else will have
> to address.  As far as I know, HL7 actually does not even vote on ISO
> standards.  I must admit that I hoped at times the differences could be
> resolved. I guess the differences are so fundamental that we can't find a
> path to harmonization.  Maybe some other group with the biases that we have
> can help resolve the situatiuon.  I am interested in seeing things brought
> together.  I think if we don't, neither of us will enjoy success at a level
> we would like to see.  More importantly, I think we won't meet the
> requirements of the global HIT community without trying to find a solution
> to the differences.  I think, and I know you don't agree, that some of the
> differences are matters of opi ion - a different way of doing things.,  I
> am using data types for ISO 21090 without any problems.  I may be to dumb
> to appreciate the difficulties.  I do admit that I am not using every data
> type.
> 
> In any case, the best to you.  I thnk openEHR has made major progress and
> is becoming an influential organization.  I do enjoy some of the
> discussions on this list server.  I am, believe it or not, learning some
> new things.  Thanks to these discussions.
> 
> Best.  Looking forward to seeing you all in January.
> 
> 
> 
> W. Ed Hammond, Ph.D.
> Director, Duke Center for Health Informatics
> 
> 
> 
> Thomas Beale  
>  aninformatics.com  To 
>>openehr-technical at openehr.org   
> Sent by:   cc 
> openehr-technical 
> -bounces at openehr. Subject 
> org   Re: ISO 21090 data types too
>   complex?
> 
> 11/06/2010 05:36  
> PM
> 
> 
> Please respond to 
>For openEHR
> technical 
>discussions
>   l at openehr.org>   
> 
> 
> 
> 
> 
> 
> 
> Hi Ed,
> 
> well since  you asked ... my list of problems, from a cursory examination:
>  The model is defined such that all data types inherit from HXIT and
>  then ANY, which contain 7 attributes specific to HL7v3 messages. This
>  means that any other types, such as BL (Boolean) inherits these
>  attributes. This is a basic modelling error, since the normal
>  approach is to separate context-specific attributes (e.g. specific to
>  the use of data values in messages, but not other uses) into
>  ?wrapper? classes. The practical effects of this modelling are
>  twofold:
>There is not a close correspondence between the 21090 idea of
>?ANY? and the typical Any/Object or other root class of most
>object-oriented type systems ? this name clash would have to be
>resolved in some way;
>an implementation of the 21090 data types is forced to have
>HL7v3 specific attributes in its base classes, and it also
>complicates the use of more orthodox modelling for such
>purposes;
>alternatively to produce a version of 21090 for use outside of
>HL7v3, a ?profile? of some kind

Run-time name constraints and appropriate use of terminologies

[Stef Verlinden]

Hi Sergio,

Term bindings in archetypes and templates

[Stef Verlinden]

For those of you interested in the 'problems' within Snomed as an ontology, 
here (http://precedings.nature.com/documents/3465/version/1) you can find a 
good and recent article describing them. This doesn't mean we shouldn't use 
Snomed, but knowing where the problems are is helpful to find solutions as 
Thomas already stated.

Cheers,

Stef


Op 11 mrt 2010, om 11:06 heeft Mikael Nystr?m het volgende geschreven:

> Hi Michael,
> 
> I agree that post-coordination is useful when mapping to SNOMED CT and it
> works well in many cases. However, to be able to create post-coordinated
> concepts the pre-coordinated "building blocks" have to already exist in the
> terminology, which are not always the case. There are sometimes also harder
> to reuse information mapped to post-coordinated concepts than
> post-coordinated concepts, because the hierarchies around the
> post-coordinated concepts are generally not so tailored for the
> post-coordinated concepts as the hierarchies around pre-coordinated concepts
> are.
> 
> It is also only SNOMED CT and a few other terminology systems that allow
> post-coordination, so for the majority of terminology systems
> post-coordination isn't possible to use.
> 
> My view is therefore still that creating archetypes and the terminology
> bindings in parallel is better than fist create the archetypes and
> afterwards add terminology bindings.
> 
>   Greetings,
>   Mikael
> 
> 
> 
> -Original Message-
> From: openehr-technical-bounces at chime.ucl.ac.uk
> [mailto:openehr-technical-bounces at chime.ucl.ac.uk] On Behalf Of
> Michael.Lawley at csiro.au
> Sent: den 11 mars 2010 01:46
> To: openehr-technical at chime.ucl.ac.uk
> Subject: Re: Term bindings in archetypes and templates
> 
> 
> Hi Mikael,
> 
> You may be interested in our mapping tool, Snapper, which is designed to
> tackle this problem for mapping to (not from) SNOMED CT.  It provides
> extensive support for mapping to post-coordinated expressions where
> single-concept maps are not possible and can be used to create unofficial
> extensions to SNOMED CT.
> 
> More details and a short screen-cast are on our website
> http://aehrc.com/snapper
> 
> Cheers,
> michael
> 
> --
> Dr Michael Lawley
> Principal Research Scientist
> The Australia e-Health Research Centre http://aehrc.com/
> +61 7 3253 3609; 0432 832 067
> 
> "Ein Fl?gel und einen Schnabel machen kein Vogel"
> 
> 
> On 11/03/10 9:49 AM, "Mikael Nystr?m"  wrote:
> 
> Thomas Beale wrote:
> 
>> On 10/03/2010 22:16, Mikael Nystr?m wrote:
> 
>>> I belong to a group that, except for openEHR related research, also do
>>> research about terminology systems and terminology systems mapping.
>>> During mapping from one terminology system to another terminology
>>> system is it quite common to be unable to map properly, because the two
>>> terminology systems have divided the domain in different ways. This
>>> problem appears even when mapping to SNOMED CT, which have a broad
>>> coverage and a concept model allowing a broad set of relationships. My
>>> view is that the same problem will appear when finalized archetypes are
>>> bound to existing terminology systems.
> 
>> it will certainly appear. The question is: for those archetype nodes that
>> it is useful to bind to terminology (likely to be 10% or less), how close
>> is the match? For example, in labs, it should be nearly spot on. For
>> anatomy, it should be pretty close. For diseases, the disease concept in
>> an archetype will assume that it is coded in the first place by
>> terminology, so the only problem there is mapping problems from ICD to SCT
>> etc. I think we need to look at the actual size of the concrete problem,
>> not its theoretical worst case.
> 
> I agree that we have to wait and see how much problems we will get. That was
> also my reason to reply to Sebastian's e-mail which told that there is no
> problem to add terminology bindings after the archetypes are finalized.
> 
> However, I didn't refer to "theoretical worst case". I referred to actual
> problems that have appeared for us during both our research work and in our
> national SNOMED CT project in Sweden.
> 
>Greetings,
>Mikael
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
> 
> 
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Interoperability with HL7

[Stef Verlinden]

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

Interoperability with HL7

[Stef Verlinden]

Op 10 feb 2010, om 14:07 heeft Bert Verhees het volgende geschreven:

> 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

I agree, but the way Gerard puts it, seems to imply it does. 

About the IP licenses. The OpenEHR board issued an e-mail on Okt 2nd 2099 in 
which they announce that:

' We have discussed the issues set out above, at length, and they cannot be 
quickly decided upon, safely. We view it as our role, at this stage, to publish 
here an interim statement of the policy issues we have identified and the 
direction of travel we are following, for the Foundation, which is as follows:
To meet immediate needs, we are minded to publish archetypes managed at 
http://www.openEHR.org/knowledge  from the Foundation under the Creative 
Commons license ? specifically the Attribute and ShareAlike (CC-BY-SA). This is 
the same license that Wikipedia is using.
We also propose, at a minimum, that the copyright of all archetypes managed at 
http://www.openEHR.org/knowledge should be assigned to the Foundation. This is 
needed to ensure that the Foundation can give permission to others to adapt the 
work (see the CC license for details).
We will continue to listen and consult on the wider issues discussed in this 
interim statement. We must align the Foundation?s approach with the 
requirements and plans of our partners in IHTSDO and EuroRec and with the 
development of the new governance framework and business plan now needed for 
the Foundation.
We will keep the plan under close review over the period ahead, as we work with 
EuroRec, IHTSDO and others to fund a major experimental and clinically driven 
project for clinical content quality assurance, embracing archetypes and 
terminology.
This interim statement is now on the wiki at 
http://www.openehr.org/wiki/display/oecom/Archetypes+-+Copyright+and+Licensing. 
Subject to any necessary rethinking as a Board, arising from responses we 
receive before December 1st 2009, we plan that it will become official openEHR 
Foundation policy from January 1st 2010, when a set of rules covering its 
implementation will also be published. We will also consider whether and in 
what form we might usefully propose guidelines for how copyright in archetypes 
might best be managed in other contexts, such as a) when managed by governments 
on national or regional servers, b) when managed privately by healthcare 
organisations, professional bodies or companies, and c) when managed 
experimentally, eg in research programmes.'

As far as I'm aware the above has become openEHR foundation policy as of 
January 1st 2010. I have to admit that these changes in the IP status can't be 
found on the openEHR homepage at this moment. Can somebody please place the 
renewed 'Statement on Copyright and Licensing of Archetypes' at a prominent 
place at the openEHR website.

Cheers,

Stef



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

Fwd: Interoperability with HL7

[Stef Verlinden]

For one or another reason  a part of the text in my reply is 'meshed' up when I 
receive it back via the mailinglist. The first sentence of my reply was 
intended to be: 

What has happened? For years and years you have been the initiator of many 
disputes between 13606/openEHR and HL7 and now all over sudden openEHR seems to 
have become the 'enemy'. 

I hope it shows up correctly this time. Does anybody know why/how this 
'mesh-up' happens?

Begin doorgestuurd bericht:

> Van: Stef Verlinden 
> Datum: 10 februari 2010 13:05:01 GMT+01:00
> Aan: For openEHR technical discussions 
> Onderwerp: Antw.: Interoperability with HL7
> 
> 
> 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 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)
> 
> 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 over sudden openEHR seems 
> 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:
> 
> A company limited by guarantee is an alternative type of incorporation used 
> primarily for non-profit organisations that require corporate status. A 
> guarantee company does not have a share capital, but has members who are 
> guarantors instead of shareholders. The guarantors give an undertaking to 
> contribute a nominal amount towards the winding up of the company in the 
> event of a shortfall upon cessation of business. It cannot distribute its 
> profits to its members, and is therefore eligible to apply for charitable 
> status if necessary. 
> 
> So I would like you to withdraw this unfunded accusation or provide some 
> solid facts to prove the contrary. This really doesn't help the discussion.
> 
> I do like the fact that you've turned around and see opportunities to 
> harmonize HL7, 13606 and openEHR, so let's keep working on that track.
> 
> 
> Cheers,
> 
> 
> Stef
> 

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

Interoperability with HL7

[Stef Verlinden]

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

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 over sudden openEHR seems 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:

A company limited by guarantee is an alternative type of incorporation used 
primarily for non-profit organisations that require corporate status. A 
guarantee company does not have a share capital, but has members who are 
guarantors instead of shareholders. The guarantors give an undertaking to 
contribute a nominal amount towards the winding up of the company in the event 
of a shortfall upon cessation of business. It cannot distribute its profits to 
its members, and is therefore eligible to apply for charitable status if 
necessary. 

So I would like you to withdraw this unfunded accusation or provide some solid 
facts to prove the contrary. This really doesn't help the discussion.

I do like the fact that you've turned around and see opportunities to harmonize 
HL7, 13606 and openEHR, so let's keep working on that track.


Cheers,


Stef

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

Interoperability with HL7

[Stef Verlinden]

Hear, hear.  Don't know if I can be of any help but count me in.

In response to Thomas reply in ISO. I agree that ISO is not the first place to 
create new standards. but it is the place to bring them to get worldwide 
acceptance. If we can come up with something that  is agreed upon by HL7, 
openEHR, ISHTDO (and maybe some other parties I'm forgetting right now) there 
is a more than fair change it will get ISO acceptance.

Cheers,

Stef


Op 1 feb 2010, om 18:07 heeft William E Hammond het volgende geschreven:

> I like your reply.  I am willing to commit to putting energy behind merging
> al  standards groups, probably under ISO.
> 
> W. Ed Hammond, Ph.D.
> Director, Duke Center for Health Informatics
> 
> 
> 
> Thomas Beale  
>  aninformatics.com  To 
>>openehr-technical at openehr.org   
> Sent by:   cc 
> openehr-technical 
> -bounces at chime.uc Subject 
> l.ac.uk   Re: Interoperability with HL7   
> 
> 
> 02/01/2010 12:02  
> PM
> 
> 
> Please respond to 
>For openEHR
> technical 
>discussions
>  l at chime.ucl.ac.uk 
>> 
> 
> 
> 
> 
> 
> 
> 
> regarding any war - me neither ;-) Ed, I hope you see that it is reasonable
> to respond in some way to disinformation like 'only use openEHR if you are
> trying to talk to openEHR systems' - on an openEHR list! Nearly the only
> problem of interest in openEHR is adding semantics to existing
> environments. It is obvious by inspection that openEHR would not need to
> exist in its current form in order to talk to itself.
> 
> There are theoretical difficulties with HL7v3 messaging & RIM, I don't
> think there is any way around that, and they do manifest in practical ways;
> there are also difficulties with CDA. But above all, I still (really,
> honestly, sincerely) want an answer from HL7 to the question:
>  how can I define a piece of domain content (microbiology result,
>  Apgar result, ENT exam, etc) once and re-use it in multiple concrete
>  technologies such as a) XSD, various GUI forms development, various
>  programming languages, and b) for various different purposes, e.g.
>  EHR persistence, messages, screen forms, and especially for creating
>  portable queries from.
> As far as I know I can't really. I can make an RMIM, or a CDA template, but
> I can't really use these together without treating them like different data
> schemas. And I can't directly re-use either for EHR persistence, querying,
> reporting or screen display or data capture. I am not saying that openEHR
> has got every last detail on this solved, but it does have large chunks
> demonstrable, including fully generated message schemas, programming
> objects, querying and reporting. The formal infrastructure is proving to be
> very solid and extensible - and yet it retains simple features like only
> one XSD for all openEHR data (well it is literally a collection of 6 or 8
> component XSDs but you know what I mean). Within the openEHR framework we
> can generate the equivalent of any HL7 message or CDA - via a tool chain
> using archetypes, templates and terminology. And we can query the date with
> archetype-based queries.
> 
> On the other hand, HL7 has a big community, much better marketing, and
> probably a better handle on use cases. To me the question about joining
> forces (which is what we in health informatics owe the world at large, I
> think) is how it can be done: it must have technical things like:
>  a solid, open formal platform framework
>  a clear, useful reference model
>  a single source domain modelling approach
>  a solid querying methodology
>  an integrated set of service definitions
>  a clean way of integrating with any terminology
> It must also have the qualities of a community:
>  a recognised meeting place and culture
>  agile but defensible governance
>  buy-in from industry
>  an on-the-ground network of affiliates
>  a wide-ranging handle on the requirements of the domain
> I would say openEHR's strengths are in the first list, and HL7's largely in
> the second - I am the first to recognise the community-related weaknesses
> of openEHR. What the world really wants here is a) ONE technical framework
> and b) ON

Interoperability with HL7

[Stef Verlinden]

Hear, hear.  Don't know if I can be of any help but count me in.

In response to Thomas reply in ISO. I agree that ISO is not the first place to 
create new standards. but it is the place to bring them to get worldwide 
acceptance. If we can come up with something that  is agreed upon by HL7, 
openEHR, ISHTDO (and maybe some other parties I'm forgetting right now) there 
is a more than fair change it will get ISO acceptance.

Cheers,

Stef


Op 1 feb 2010, om 18:07 heeft William E Hammond het volgende geschreven:

> I like your reply.  I am willing to commit to putting energy behind merging
> al  standards groups, probably under ISO.
> 
> W. Ed Hammond, Ph.D.
> Director, Duke Center for Health Informatics
> 
> 
> 
> Thomas Beale  
>  aninformatics.com  To 
>>openehr-technical at openehr.org   
> Sent by:   cc 
> openehr-technical 
> -bounces at chime.uc Subject 
> l.ac.uk   Re: Interoperability with HL7   
> 
> 
> 02/01/2010 12:02  
> PM
> 
> 
> Please respond to 
>For openEHR
> technical 
>discussions
>  l at chime.ucl.ac.uk 
>> 
> 
> 
> 
> 
> 
> 
> 
> regarding any war - me neither ;-) Ed, I hope you see that it is reasonable
> to respond in some way to disinformation like 'only use openEHR if you are
> trying to talk to openEHR systems' - on an openEHR list! Nearly the only
> problem of interest in openEHR is adding semantics to existing
> environments. It is obvious by inspection that openEHR would not need to
> exist in its current form in order to talk to itself.
> 
> There are theoretical difficulties with HL7v3 messaging & RIM, I don't
> think there is any way around that, and they do manifest in practical ways;
> there are also difficulties with CDA. But above all, I still (really,
> honestly, sincerely) want an answer from HL7 to the question:
>  how can I define a piece of domain content (microbiology result,
>  Apgar result, ENT exam, etc) once and re-use it in multiple concrete
>  technologies such as a) XSD, various GUI forms development, various
>  programming languages, and b) for various different purposes, e.g.
>  EHR persistence, messages, screen forms, and especially for creating
>  portable queries from.
> As far as I know I can't really. I can make an RMIM, or a CDA template, but
> I can't really use these together without treating them like different data
> schemas. And I can't directly re-use either for EHR persistence, querying,
> reporting or screen display or data capture. I am not saying that openEHR
> has got every last detail on this solved, but it does have large chunks
> demonstrable, including fully generated message schemas, programming
> objects, querying and reporting. The formal infrastructure is proving to be
> very solid and extensible - and yet it retains simple features like only
> one XSD for all openEHR data (well it is literally a collection of 6 or 8
> component XSDs but you know what I mean). Within the openEHR framework we
> can generate the equivalent of any HL7 message or CDA - via a tool chain
> using archetypes, templates and terminology. And we can query the date with
> archetype-based queries.
> 
> On the other hand, HL7 has a big community, much better marketing, and
> probably a better handle on use cases. To me the question about joining
> forces (which is what we in health informatics owe the world at large, I
> think) is how it can be done: it must have technical things like:
>  a solid, open formal platform framework
>  a clear, useful reference model
>  a single source domain modelling approach
>  a solid querying methodology
>  an integrated set of service definitions
>  a clean way of integrating with any terminology
> It must also have the qualities of a community:
>  a recognised meeting place and culture
>  agile but defensible governance
>  buy-in from industry
>  an on-the-ground network of affiliates
>  a wide-ranging handle on the requirements of the domain
> I would say openEHR's strengths are in the first list, and HL7's largely in
> the second - I am the first to recognise the community-related weaknesses
> of openEHR. What the world really wants here is a) ONE technical framework
> and b) ON

{Disarmed} Re: Interoperability with HL7

[Stef Verlinden]

Op 1 feb 2010, om 10:33 heeft Charlie McCay het volgende geschreven:

> More is needed to ensure that information can be safely reused and combined.  

Dear Alberto,

Can you please explain what this 'more' is and provide some examples for a 
non-technical person like myself.

Cheers,

Stef

Op 1 feb 2010, om 10:33 heeft Charlie McCay het volgende geschreven:

> Alberto
> 
> I would say that EHR systems based on the openEHR specification face similar 
> interoperability challenges to to those based on other proprietary or open 
> source architectures.  
> 
> I will take a step back and observe that two implementations of openEHR or 
> any other EHR system design will not interoperate fully unless there are 
> coherent information structures used.   This is certainly true of a system as 
> flexible as that defined by the openEHR architecture.
> 
> Agreeing on a reference model (HL7 RIM, 13606, openEHR, ...) and a 
> terminology certainly helps, but even with that agreement in place there are 
> many ways to represent the same clinical content.  More is needed to ensure 
> that information can be safely reused and combined.  Within an openEHR 
> installation this is achieved by using a single coherent set of archetypes, 
> much as data structures are localised in other EHR architectures.  
> 
> If your requirement is limited to communicating within an openEHR community, 
> then developing and agreeing to use a suite of common archetypes and 
> templates is sufficient.  If you wish to interoperate with the broader 
> healthcare information systems installed base, then it makes sense to work 
> with HL7 specifications which are focused on delivering this, and broadly 
> adopted for this purpose. 
> 
> For external communication of entry-level detail using HL7v3 there is a need 
> for agreed static models  (R-MIMs).  These are implemented as templates (eg 
> with CDA), or as CMETs in V3 messaging - and a corresponding sets of 
> archetypes for 13606 or openEHR can be defined if these are what you use to 
> configure your system.   
> 
> All the best
> 
> Charlie
> 
> 
> -- 
> Charlie McCay, charlie at RamseySystems.co.uk
> Ramsey Systems Ltd, 23D Dogpole, Shrewsbury, Shropshire SY1 1ES
> tel +44 1743 232278 / +44 7808 570172  skype: charliemccay   
> linkedin:charliemccay
> 
> 
> 
> From: Thomas Beale 
> Organization: Ocean Informatics
> Reply-To: For openEHR technical discussions  chime.ucl.ac.uk>
> Date: Sun, 31 Jan 2010 23:30:22 +
> To: 
> Subject: Re: Interoperability with HL7
> 
> On 29/01/2010 07:41, Alberto Moreno Conde wrote: 
>> I would like to address the interoperability with the HL7 standards. As I 
>> understand it is possible to map between OpenEHR to HL7 CDA, this allows us 
>> to create systems that are based on the openEHR reference model compatible 
>> HL7. This system would be able to send HL7 v2 and HL7 v3 messages from the 
>> CDA  and EHR_EXTRACTS from the OpenEHR reference model.
>>  
>> I don't understand what consequences have that the HL7 RIM is still not 
>> fully compatible with the OpenEHR reference model if we can send messages 
>> from HL7 CDA.
>>  
>> Is there other problems in the interoperability between HL7 and OpenEHR? 
>>  
>> I hope that Thanks 
>>  
>> Alberto 
>> 
> 
> Hi Alberto,
> 
> In practical terms, performing mapping between HL7v2 messages and openEHR, 
> and also CDA and openEHR is certainly possible. It takes some work - the 
> complexity of the HL7 RIM doesn't make it that easy for CDA or other v3-based 
> structures. 
> 
> In a theoretical sense, the key thing to understand is that in HL7 there is a 
> pervasive approach of restriction-based modelling - in the RIM, the 
> data-types, and all *MIMs. In this kind of modelling, abstract classes have 
> numerous attributes, in theory all that would ever be needed, and descendant 
> classes are defined as restrictions of the parents. You will have noted for 
> example that the Act class in the RIM has 22 attributes, and the 
> Act-relationship class 18. I won't go into the problems that this causes, but 
> there is one other key fact to note: the RIM classes contain a mixture of 
> domain information related attributes and message-related attributes. 
> However, if your interest is not hand-building messages, it can be hard to 
> see past these attributes to get a pure domain model of the concept in 
> question, e.g. cholesterol test result, or whatever. This is one of the 
> reasons CDA has become popular, because it is a more generic, less 
> message-oriented RMIM than other message types. It nevertheless contains the 
> same fine-grained (level 3) concepts as the RIM, albeit in a restricted form. 
> 
> At a more concrete level of analysis, you need to compare the reference 
> models. The openEHR reference model is a standard OO style of modelling, and 
> has been heavily influenced by the development of archetypes over the years. 
> It now appears to accommodate most clinical models pretty naturally and has 

Meaningful use criteria

[Stef Verlinden]

Is anybody following the current discussion in the US about the meaningful use 
citeri and/or is anybody actively involved?

The published criteria can be found here: 
http://frwebgate5.access.gpo.gov/cgi-bin/PDFgate.cgi?WAISdocID=467405454267+0+2+0&WAISaction=retrieve

Is just scanned it very quickly and one thing stroke me, this is just a 
pre-definition.: 'In order for an EHR technology to be eligible for 
certification it must first
meet the definition of a qualified electronic health record. This term will be 
defined by ONC in its upcoming interim final rule, and we propose to use the 
definition of qualified electronic health record adopted by ONC.'

So it appears that the ONC final rule will set an important road ahead for the 
coming decades. Is anybody promoting the benifits of the 13606 standard and if 
not shouldn't we do that?


Cheers,

Stef


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

data types and structures questions

[Stef Verlinden]

Hi Sebastian,

Op 21 dec 2009, om 08:50 heeft Sebastian Garde het volgende geschreven:

> A Cluster you could "plugin" anywhere within an archetype e.g.  
> somewhere deep down in the data, protocol or state, an ITEM_TREE (or  
> any other structure archetype such as ITEM_LIST, ITEM_SINGLE and  
> ITEM_TABLE) where an ITEM_* structure is expected - e.g. the top- 
> level of data, protocol, state

Is there a specific reason for this of is is just to keep an archetype  
'tidy'?

Cheers,

Stef

informal poll: openEHR conference

[Stef Verlinden]

+1 (but any other location where we can have both a good meeting and a  
good social event will do). I like the train suggestion.

Cheers,

Stef


Op 29 nov 2009, om 00:49 heeft Koray Atalag het volgende geschreven:

> Hi Tom, having such a social get together would be very niceI'd  
> vote for Amsterdam :)
>
> Cheers,
>
> -koray
> 
> From: openehr-technical-bounces at chime.ucl.ac.uk [openehr-technical- 
> bounces at chime.ucl.ac.uk] On Behalf Of Thomas Beale  
> [thomas.beale at oceaninformatics.com]
> Sent: Sunday, 29 November 2009 8:57 a.m.
> To: For openEHR technical discussions
> Subject: Re: informal poll: openEHR conference
>
> I forgot to mention: personally I would like it to be an  
> environmentally conscious event (in as much as any conference could  
> be), and one thing I would at least try for is a destination that  
> allow many people to go by train rather than by plane. Sam and I  
> once did London - Maastricht (which by the way is also a good  
> location) on the train in 7.5h (1.5h wait in Brussels) compared to  
> what we calculated as 5h by plane. But we got 6h work done, and 1h  
> drinking Belgian beer. I consider that a successful journey. Of  
> course not much can be done about long haul flying from the US and  
> down-under.
>
> Another priority for me would be the idea that it would not repeat  
> every few months like standards meetings, maybe not even every year  
> (a bi-annual event maybe?) - so we could afford to spend some time  
> together as a community. Also, I would put as much value on the  
> networking and social side of things as on the 'business of openEHR'  
> - which means finding a nice destination, one that works perfectly  
> well if people want to have a holiday, with kids, partners etc.
>
> The cost might also be an important consideration for most people,  
> although if it were say every 2 years, it may not matter as much as  
> for standards meetings which just keep happening.
>
> these are just personal thoughts; it could only happen if enough  
> people in the community would sign up to the idea to make it viable.
>
> - thomas beale
>
>
> Mikael Nystr?m wrote:
> I guess that the social activities would be quite important for the  
> community and they are hard to organize on airports and train  
> stations. I therefore vote for other locations than airports and  
> train stations.
>
>  Greetings,
>  Mikael
>
>
> From: openehr-technical-bounces at 
> chime.ucl.ac.uk > [mailto:openehr-technical-bounces at chime.ucl.ac.uk] On Behalf Of  
> Bert Verhees
> Sent: den 27 november 2009 17:38
> To: openehr-technical at openehr.org technical at openehr.org>
> Subject: Re: informal poll: openEHR conference
>
> An international airport/train station nearby would be good, it  
> saves days of traveling.
>
> Bert
>
> Op 27-11-09 17:25, Thomas Beale schreef:
>
> This is an initial informal question to the community about interest  
> in an openEHR conference / meeting, probably initially located in  
> Europe. Possibly activities:
>
> *   presentations / papers on commercial & academic projects
> *   technical working design sessions for major upcoming  
> specifications
> *   clinical modelling design sessions / presentations /  
> discussions / debates
> *   meetings aimed at making decisions about the running &  
> governance of openEHR, enabling future organisational improvement
> *   professional and academic networking activities
> *   some purely social activities.
> purely as an example of a nice location at which social and outdoor  
> activities can take place, Lake Bled in Slovenia has been suggested,  
> of course there are many other wonderful locations. I have heard  
> many requests for a conference over the last few years, so I wonder  
> what the reaction & interest of the community to this suggestion  
> would be.
>
> - thomas beale
>
>
>
>
>
>
>
>
> ___
>
> openEHR-technical mailing list
>
> openEHR-technical at openehr.org
>
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>
>
>
>
> 
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
>
> --
> [cid:part1.05030002.04040909 at oceaninformatics.com]  Thomas Beale
> Chief Technology Officer, Ocean Informatics >
>
> Chair Architectural Review Board, openEHR Foundation >
> Honorary Research Fellow, University College 
> London >
> Chartered IT Professional Fellow, BCS, British Computer 
> Society >
> Health IT bl

License and copyright of archetypes

[Stef Verlinden]

Hi Erik,

I see your point and agree. My call for the -SA extension was based on  
the idea of reciprocity. So let's go for CC-BY.

Cheers,

Stef

(I sended this reaction earlier but for an unknown reason only to  
Eric. So now for the whole group. Although I still believe in the idea  
of reciprocity and would like to advocate for it, a license shouldn't  
become a hindrance for the broad usage of openEHR archetypes and/or a  
'paper tiger' as we call it in the Netherlands: don't create rules  
which you can't (or don't want to) follow up)

Op 14 sep 2009, om 12:14 heeft Erik Sundvall het volgende geschreven:

> Requiring SA in addition to BY might add value or it might mostly add
> complications and hard-to-interpet situations regarding what a
> derivative work is. Is data entered using the archetype a derivative  
> work?
> Is a template or screen-form based on the archetype a derivative work?
> Is a book using the archetype in an example a derivative work? A
> specialization of an archetype intended for top-secret medical
> research is most likely a derivative work, is that a problem or not?  
> It
> is issues like these that get companies uneasy regarding using things
> with SA-licencing-schemes (such as GPL) in some situations.
>
> Another question is if SA is necessary in an openEHR-based health
> record exchange system. If you want to exchange archetyped data you're
> probably in most cases requested to supply the used archetype too
> anyway.

Documentation Desparation

[Stef Verlinden]

+2

Stef

Op 26 sep 2009, om 08:13 heeft Grahame Grieve het volgende geschreven:

> +1
>
> Grahame
>
> Sent from my iPhone
>
> On Sep 25, 2009, at 6:23 PM, Koray Atalag   
> wrote:
>
>> Hi All,
>>
>> I really appreciate the "mental" exercise to achieve a better  
>> documentation; however I must say I am really surprised to watch  
>> the recent discussions like this one because I wonder if we, as a  
>> community yet to solve many fundamental problems and overcome the  
>> many challenges, have enough resources to deal with this at the  
>> moment. Frankly I disagree with the need to translate all the specs  
>> and documentation into other languages at the moment - not to say  
>> that this is trivial but I don't think we are at that stage at the  
>> moment. And when we become (if ever!) a multi-million $$$  
>> foundation then I suggest looking at how ISO or national bodies  
>> approach the multi-lingual documentation problem.
>>
>> While I believe in and most importantly own a couple open source  
>> projects myself, I see many from FOSS rounds getting into the  
>> pitfall of seeing software as either evil or good or having the  
>> illusion of open source as a merit by itself. That is not true...I  
>> hope we don't end up trying to FOSS everything "just for the sake  
>> of" the "open" in our prefix ;)
>>
>> And ?eref I don't think much people left in Turkey to bother with  
>> openEHR anyways!
>>
>> Cheers,
>>
>> -koray
>>
>> Seref Arikan wrote:
>>>
>>> Tom,
>>> I'd be happy to help you out, just let me know what you need me to  
>>> do. I'll be putting all of the documentation into Eclipse plugins  
>>> of Opereffa anyway. We can turn that task into an experiment to  
>>> lay out some sort of method for transformation of documentation to  
>>> other formats.
>>>
>>> Cheers
>>>
>>>
>>> On Fri, Sep 25, 2009 at 6:08 PM, Thomas Beale >> oceaninformatics.com 
>>> > wrote:
>>>
>>> Unfortunately I can't make any conversion mission a top priority,  
>>> but let's commit at least to an experiment which I can initiate -  
>>> I will generate the 'standard as-is' XML output from one  
>>> specification (say the data types) and make that available - Seref  
>>> or someone else may be able to determine what rules it is  
>>> following; in the meantime I can do a bit of research on what  
>>> needs to be done to a FM document to make its XML output DITA based.
>>>
>>> - thomas
>>>
>>>
>>> Tim Cook wrote:

 Hi Seref,

 Thanks for your concerns and well thought out points.

 If you read my original posting, I didn't ask Tom to stop using
 Framemaker.  I ask for some output in place of (or in addition  
 to) the
 PDF and Framemaker formats.  I'll happily accept .doc files at this
 point.

 It seems that we have a different perspective on what the sense  
 of trust
 in the community is also.  But that is an entirely other  
 subject.  :-)

 --Tim


 On Fri, 2009-09-25 at 11:08 +0100, Seref Arikan wrote:

> Dear all,
> I'd like to express my concerns about practical outcomes of  
> suggested
> changes, changes based on potential benefits. I'd appreciate your
> input about the use cases we are discussing just to make sure  
> that I
> get this right.
> First of all, translation of openEHR documentation to other  
> languages
> is a very critical task, which would be quite a challenge,  
> because we
> are talking about very high quality documentation, to which I keep
> going back quite often, mostly to find out that a point that I was
> missing has already been there, expressed carefully. At one  
> point I've
> thought about translating the docs to Turkish, my mother tongue,  
> and
> realized that not having a Framemaker licence was the least of my
> problems. Reflecting the same quality, and more important than  
> that,
> the same semantics consistenty in other languages is a huge  
> challange.
> It requires understanding of the domain, the standard, and  
> possesion
> of more than ordinary control over two languages, one being  
> English.
> Also, as a member of openEHR community I would not like to see
> translations of the specs in the wild, with no official approval  
> or
> inclusion from openEHR foundation, since this can easily lead to
> confusing documentation on an already confusing topic, which is
> challanging enough to master with really good docs.
> I would like to know if there are efforts, or even intentions of
> translating this documentation to other languages, and the  
> owners of
> these intentions. How many translations of the documentation  
> will be
> for Spanish for example? If a person would give this task a try,  
> due
> to reasons expressed above, he/she would have to possess quite a  
> lot
> of time, skills  and he/she would have t

Concept Overload Caution

[Stef Verlinden]

Hi Heath,

I complety agree with you. Let's all do what we're best at. What I  
would like to add to your proposal is some feedback (both ways) so  
doctors and technicians can learn from eachother. Rather than de- 
empowering the one or the other I think we should team up to create a  
properly working system that really adds value for the citizens/ 
patient who are the subject of this all.

Also as I clinician I really would like an understandable (at  
technical lay-mans level) manual with clear examples who things can  
work and why some solutions shoudl be avoided. Maybe some best- 
practices of whatever you like to call that

Cheers,

Stef

Op 23 jun 2009, om 02:15 heeft Heath Frankel het volgende geschreven:

> Hi Tim,
> Thank you for your post, I complete agree.  Like you I am not a  
> clinician
> and feel that I am rocking the establishment of openEHR and the  
> principles
> of Archetypes by saying this, but I strongly believe that we need to  
> have a
> technical review process of archetypes before they are published.   
> What I am
> looking to review is not related to the clinical content, but the  
> patterns
> used to represent that clinical content.  In particular, I would  
> looking to
> ensure that we have single concept representation, loose coupling,
> reusability, appropriate use of specialisation, and most importantly I
> believe, appropriate structures to support querying.  These are all  
> good
> object-oriented (or general software) design principles that  
> technicians are
> trained to be better at then clinicians.
>
> As part of the archetype governance and publishing process, I would  
> like to
> see a technical review process.
>
> I realise I am writing to a group of technicians on this list and  
> this is
> probably a topic for the clinical list, but I think there probably are
> enough clinicians on this technical list to knock me around if they  
> feel
> that I am rocking it too hard.
>
> Please understand that I not trying to re-empower the technician, I am
> simply looking for good quality knowledge artefacts and believe this a
> process that is missing in the current archetype development process.
>
> Regards
>
> Heath
>
>> -Original Message-
>> From: openehr-technical-bounces at openehr.org [mailto:openehr- 
>> technical-
>> bounces at openehr.org] On Behalf Of Tim Cook
>> Sent: Wednesday, 3 June 2009 9:59 AM
>> To: For openEHR technical discussions
>> Subject: Concept Overload Caution
>>
>> Hi All,
>>
>> The past 3 or 4 subjects on this list takes me back to conversations
>> that we had before (maybe several years ago?) when we were discussing
>> slots and links.  Maybe they were here maybe they were on the ARB  
>> list.
>> I do not recall now.
>>
>> But my feeling in both of these areas are that there is a tendency  
>> for
>> archetype developers to create archetypes that are more than one
>> clinical concept.  IIRC, that is about the time that templates were
>> being thought of/designed to alleviate the pressure on archetypes to
>> serve everyone, everywhere.
>>
>> As Heath has just mentioned, templates are the better place for this
>> type of grouping.  They tend to provide that ability to be more
>> localized.  Remember that when you are creating or reusing archetypes
>> that they should be universally reusable.  If they are not, then they
>> do not meet the basic requirement of being a single clinical concept.
>> This is fundamental to openEHR being future proof.
>>
>> The misuse of slots and probably any use of links in a particular
>> archetype; IMHO is a very bad thing and will lead us down the road  
>> that
>> we see with data model centric systems as opposed to our information
>> model.
>>
>> While I am not a clinician nor a lab tech I do ask those of you
>> creating archetypes to review the fundamental principles of  
>> archetypes
>> and templates.  Then think twice before publishing an artifact.
>>
>> From what I am reading I think that there is becoming a tendency to  
>> put
>> too much runtime functionality into what is supposed to be singular
>> data items.
>>
>> My 2 cents/pence/centavos
>>
>> --Tim
>>
>>
>>
>>
>>
>> --
>> Timothy Cook, MSc
>> Health Informatics Research & Development Services LinkedIn
>> Profile:http://www.linkedin.com/in/timothywaynecook
>> Skype ID == timothy.cook
>> **
>> *You may get my Public GPG key from  popular keyservers or   *
>> *from this link http://timothywayne.cook.googlepages.com/home*
>> **
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Announcement of the release of Opereffa by the openEHR Foundation

[Stef Verlinden]

Dear Tony, David and Seref,

Congratulations to you (and to the openEHR community).

This is truly very good news, great work and a major milestone for the  
openEHR community.
I'm confident that this will boost many efforts that are out there a  
helps to focus our energy as well as to show the outside world what  
really can be done with openEHR.


Cheers,

Stef


Op 10 jun 2009, om 10:11 heeft Thomas Beale het volgende geschreven:

>
> Announcement of the release of Opereffa by the openEHR Foundation
>
> The openEHR Foundation is pleased to announce the early release of  
> Opereffa ? openEHR REFerence Framework and Application, under  
> development at UCL.
>
> As healthcare systems are under increasing pressure,  
> internationally, they are exploring improvements in health  
> information systems, as a key way to survive and thrive in the 21st  
> century. As a means to support these efforts, members now working  
> under the umbrella of the openEHR Foundation have been developing  
> and implementing open specifications for an Electronic Health Record  
> for many years, and these have since formed the basis of the ISO and  
> CEN 13606 archetype standard.
>
> In response to a recent exploration of the openEHR international  
> clinical community?s requirements, by the openEHR Clinical Review  
> Board Chair Dr Tony Shannon, an open source clinical reference  
> application, focused on early clinical benefit and usability, was  
> deemed to be an important next step for the community.
-- next part --
An HTML attachment was scrubbed...
URL: 

Reverse_relationships

[Stef Verlinden]

I've been working through the demographic AT's that were provided by  
Sergio. It's probably due to my lack of technical knowlegde but I  
can't find where reverse_relationships are defined in these  
archetypes. Or it must be in openEHR-DEMOGRAPHIC- 
ROLE.health_consumer.v1 under:
relationships matches {

 PARTY_RELATIONSHIP[at0010]  
matches {-- relationship between a health consumer and a  
third-party payer

 details matches { --  
we gaan er klaarblijkelijk vanuit dat er maar 1 relatie kan bestaan  
met zorgverzekeraar

  
allow_archetype CLUSTER[at0011]matches { -- identifier  
used in the relationship

 include


 archetype_id 
/value matches {/([a-zA-Z0-9_]+)*(identifier)\.v1/}



In that case I probably don't understand how this works. From what I  
read in the demographic_im there shoudl be by references to the   
HIER_OBJECT_IDs

Can somebody help me to understand this and possible explain how to  
create such an reverse_relationship in an AT.



Cheers,



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

2009 and beyond

[Stef Verlinden]

Dear Tony,

You're the new chair now for almost 6 months. Can you provide us with  
some views/ outlooks of what is going to happen in 2009 and beyond.

Are there any plans/ ideas to set up an official (top level?)  
archetype repository so that one unified set of archetypes is being  
created. If such a thing isn't installed quickly we run into a big  
risk that everbody starts using their 'home brewed' archetypes. In  
that case interoperability will be lost and if one wants to create  
that we have to harmonise/ map all those archetypes a few years from  
now. I can't imagine that's the idea behind openEHR.

Cheers,

Stef

is OpenEHR.org down?

[Stef Verlinden]

Here it's also still down


Op 12 jan 2009, om 08:38 heeft Seref Arikan het volgende geschreven:

>
> Unfortunately that is not the case for me at the moment. Still down?
>
> Best
> Seref
>
> On Sun, Jan 11, 2009 at 8:27 PM, Ian McNicoll  oceaninformatics.com 
> > wrote:
> It is back working now
>
> Ian
>
> On 1/11/09, Stef Verlinden  wrote:
> > It seems down indeed.
> >
> > Cheers,
> >
> > Stef
> >
> >
> > Op 11 jan 2009, om 14:34 heeft Seref Arikan het volgende geschreven:
> >
> >> Hi there,
> >> I can not access to openehr.org from Turkey at the moment, and I've
> >> also tried a proxy in USA. Is it me only, or is the site down?
> >>
> >> Kind Regards
> >> Seref
> >> ___
> >> openEHR-technical mailing list
> >> openEHR-technical at openehr.org
> >> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
> >
> >
>
>
> --
> 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
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
> ___
> 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: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090112/59914fbe/attachment.html>

is OpenEHR.org down?

[Stef Verlinden]

It seems down indeed.

Cheers,

Stef


Op 11 jan 2009, om 14:34 heeft Seref Arikan het volgende geschreven:

> Hi there,
> I can not access to openehr.org from Turkey at the moment, and I've  
> also tried a proxy in USA. Is it me only, or is the site down?
>
> Kind Regards
> Seref
> ___
> 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: 

Insight into the choices to be made in standards for the electronic exchange of health record information

[Stef Verlinden]

Eric,

To be clear, it is not my document. It is the document created by the  
members of the Dutch mirror group on, to which I've contributed. Like  
I stated it's a consensus document which is great but also created  
many boundaries to the extend we could extend the discussion. So  
don't shoot the messenger.

Op 8-okt-2008, om 11:16 heeft Eric Browne het volgende geschreven:

> Stef,
>
> I don't question your intentions, but I definitely question the value
> of such a document in helping the discussions at CEN and ISO level. I
> can only see it confusing the already muddied waters. You simply
> cannot advance the cause of harmonisation of standards, or choosing
> between standards, by dumbing down the issues to such an extent!
>
> I'm sorry, Stef, if my response seems brutally rude, but I'm sure that
> the level of debate at CEN and ISO must be more sophisticated than the
> simplistic suggestions embodied in your document. If not then we are
> centuries away from the sort of IT-enabled healthcare systems that
> many of us can imagine.

I'm sorry to disturb your sweet dreams, but this is the level of  
debate that takes place at least at NEN. I'm not aware of more  
sophisticated discussions at the level of CEN of ISO.

Please feel free to post your brilliant contribution to this debate  
so we can educate the less sophisticated among us.

>
> And as for your analogy regarding the "Dutch Syndrome", we are not
> talking about marketing a product, we are talking about standards and
> specifications for e-health interoperability, decision support and
> much more, that affect our own health and the health of others.

>
> Please reconsider taking your document to those meetings.

Again it's not my document and not my decission and if you had taken  
the time to read my mail properly you could have known that.
Luckely the Istanbul meeting is in 2 weeks so there is plenty of time  
to come up with an alternative document in which al of your brilliant  
analyses are put togehter. I really encourage you to do so.

Cheers,

Stef
>
> regards,
> eric browne
>
> On 08/10/2008, at 7:05 PM, Stef Verlinden wrote:
>
>> Thomas.
>> Op 7-okt-2008, om 17:10 heeft Thomas Beale het volgende geschreven:
>>
>>> Governments need to understand these realities, or they will
>>> continue to find it difficult to see how to apply any of the
>>> competing standards available today. I have to say that I don't
>>> find this report particularly helpful, because it gives very little
>>> in the way of really solid advice on how governments should move
>>> forward.
>>
>> Although I agree with you, you also know where we're coming from: a
>> situation where two camps dug in deep, proclaimed that their
>> solution was the best and didn't want to look over the fence. This
>> is a consensus document generated by all parties involved and as
>> such a big step ahead.
>>
>> Another thing is that this document is about the interational EHRCOM
>> standard 13606 and not about all the fantastic things we could do
>> once openEHR derived commercial solutions finally become widely
>> available. Since openEHR isn't an international standard, nor widely
>> implemented as a commercially  product, so that people can see it's
>> beneifits, your remarks seem academic. Furthermore it's intended
>> audience is the people at CEN and ISO, not governments. For that
>> purpose we'll try to create a less technical document.
>>
>> I completely agree with your remark that Governments need to
>> understand these realities. Again I'll invite everbody to come up
>> with clear examples, proof and/or bussiness models, which are
>> understandable for decission makers (technical lay-man) so they can
>> get a good understanding of these realities and the consequences of
>> their choices. So far the discussion is only accesible for the happy
>> few who have the time, enthousiams and (some degree of:-)) technical
>> understanding to dug in deep. To convince an average decission maker
>> you have a couple of minutes. If we (as the openEHR community)
>> aren't capable of selling 'our' product to these decission makers in
>> an understandable and concise manner, we still have the best product
>> in the world but nobody will use it. So far I haven't seen any
>> document/ example/ bussiness case that can convince a decission
>> maker/ goverment why they should consider using openEHR.
>>
>> As you might know this is what we call the Dutch or Philips syndrome
>> over here: Back in the eighties Philips created an brillant n

Insight into the choices to be made in standards for the electronic exchange of health record information

[Stef Verlinden]

Thomas.
Op 7-okt-2008, om 17:10 heeft Thomas Beale het volgende geschreven:

> Governments need to understand these realities, or they will  
> continue to find it difficult to see how to apply any of the  
> competing standards available today. I have to say that I don't  
> find this report particularly helpful, because it gives very little  
> in the way of really solid advice on how governments should move  
> forward.

Although I agree with you, you also know where we're coming from: a  
situation where two camps dug in deep, proclaimed that their solution  
was the best and didn't want to look over the fence. This is a  
consensus document generated by all parties involved and as such a  
big step ahead.

Another thing is that this document is about the interational EHRCOM  
standard 13606 and not about all the fantastic things we could do  
once openEHR derived commercial solutions finally become widely  
available. Since openEHR isn't an international standard, nor widely  
implemented as a commercially  product, so that people can see it's  
beneifits, your remarks seem academic. Furthermore it's intended  
audience is the people at CEN and ISO, not governments. For that  
purpose we'll try to create a less technical document.

I completely agree with your remark that Governments need to  
understand these realities. Again I'll invite everbody to come up  
with clear examples, proof and/or bussiness models, which are  
understandable for decission makers (technical lay-man) so they can  
get a good understanding of these realities and the consequences of  
their choices. So far the discussion is only accesible for the happy  
few who have the time, enthousiams and (some degree of:-)) technical  
understanding to dug in deep. To convince an average decission maker  
you have a couple of minutes. If we (as the openEHR community) aren't  
capable of selling 'our' product to these decission makers in an  
understandable and concise manner, we still have the best product in  
the world but nobody will use it. So far I haven't seen any document/  
example/ bussiness case that can convince a decission maker/  
goverment why they should consider using openEHR.

As you might know this is what we call the Dutch or Philips syndrome  
over here: Back in the eighties Philips created an brillant new and  
innovative product: a videoplayer called Video 2000. Since everybody  
was convinced that such an superior system would sell itself not much  
attention was paid to marketing.
At the same time a videoplayer which was on all fronts inferior to  
the Philips player was developped: the VHS player. Since it's  
producers knew that marketing was key, they promoted the product as  
aggresively as they could and with great succes. Since for the end  
user the VHS already was a big step forward (untill then there was no  
way to record and play video at home)  and all they heard about was  
VHS they bought into that system and took over the market. Any  
simllarities here?


Cheers,

Stef

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

Insight into the choices to be made in standards for the electronic exchange of health record information

[Stef Verlinden]

For those of you interested: here (http://www.vivici.nl/ 
insight_into_choices_to_be_made/ ) you can download the translated  
version of the document we've created within the Dutch mirror group  
on information models & messages.
This document will be presented at the joint ISO/TC 215 Health  
Informatics and CEN/TC 251 Health Informatics meeting in Instanbul  
later this month.  Hopefully it contributes to an even better  
discussion about choices to be made in the various CEN/ISO member  
countries.

Cheers,

Stef

eHealth-INTEROP Report in response to EU Mandate/403-2007

[Stef Verlinden]

Dear all,

Today the final draft of the eHealth-INTEROP Report in response to EU  
Mandate/403-2007 was published. The report can be downloaded from:  
http://www.ehealth-interop.nen.nl/
Comments and suggestions to this document can be made to NEN untill  
october 22th.

Scope:
The European Commission has issued in 2007 a mandate to the European  
Standardization Organizations (ESOs), CEN, CENELEC, and ETSI, to  
develop a coordinated work programme for standardization in health  
informatics (Mandate M/403).
A Coordination Group of the three ESOs has been established to  
collaborate on the preparation of the 10 work programme in  
consultation with other activities as appropriate; the detailed  
process is contained in the technical proposal for the work, at Annex A.
The above-mentioned work programme will be provided in the form of an  
overview report analysing existing work and requirements and contain  
a list of proposed work items for possible standards action.
The resulting report will be submitted to the European Commission as  
required by the mandate for 15 approval and subsequent execution by  
the three ESOs as phase 2 of the mandate.
Objective
The objective [...] is to carry out phase one of the European  
Commission (EC) Mandate M/403 by providing an analysis and planning  
of existing relevant standards, specifications and technical reports  
(with short descriptions), including work under way, and the creation  
of a proposed coordinated work 20 programme for standardization in  
health informatics (eHealth) to be carried out by CEN, CENELEC and  
ETSI. This programme will cover tasks needed to achieve the goals  
with priorities to be identified for those deliverables that require  
an earlier adoption..
Priority 1:
resolve the inconsistencies, or at least facilitate co-existence,  
between standards based on fundamentally different principles (e.g.  
Electronic Records exchange formats using either CEN
13606 or HL7 RIM based documents);

Since, in my opinion, this document will become the roadmap for e- 
health interoperability in Europe, it's important to understand it's  
implications and if these aren't defined well enough to provide  
input/ comments in order to make it better.

So please read it carefully and if you have any comments and/or  
suggestions please send them either directly to NEN  
(shirin.golyardi at nen.nl) or through me. If you do, please send a CC  
to this list, so everybody can follow this discussion.

Cheers,

Stef


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

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

[Stef Verlinden]

Dear Georg,

Op 24-jun-2008, om 12:16 heeft Georg Duftschmid het volgende geschreven:

> I am now wondering why an EHR reference model is seen to be  
> REQUIRED for achieving functional interoperability. If I exchange  
> bare PDF-documents (without any describing metadata) between two  
> EHR systems, then I would say there is a good chance that these  
> docs are readable by a human receiver and thus functional  
> interoperability should be achieved although clearly an EHR  
> reference model is not used.

Theoretically you're right; there is a good change that these docs  
are readable by human. The real question is: are these usable?

Maybe such documents are usable between two health care providers who  
know and trust each-other. But now I receive such a document from   
somebody I don't/ superficially know. Am I willing to use  
(potentially critical) information in the treatment of my patient  
without knowing the proper context. By doing so I'll take over the  
responsibility. So if now my patient dies based on wrong  
interpretation of the incomplete information I'm liable for the death  
of that patient

So I would never use that information and do everything all over  
again. Why shouldn't I, I'm getting paid for this double work as well  
(as least here in the Netherlands this holds true and this is what we  
call 'perverse incentives').
Thing is that if we leave room to doubt the quality of the  
information and/or are not able to create insight in the  
responsibilities and the transfer thereof, people won't use it. In  
that case  what's the use of an EHR in the first place?

Cheers,

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

Decision Support was: MIE-2008

[Stef Verlinden]

Hi Ian and Gerard,

Could you please explain what post-coordination is and maybe provide  
an example of post- (and pre-?) coordination?

Cheers,

Stef

Op 5-jun-2008, om 0:48 heeft Ian McNicoll het volgende geschreven:

>  "most
> post-coordination (using modifiers in Snomed-space instead of
> Archetype/Template space) must end",

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

openEHR Querying specifications

[Stef Verlinden]

Op 4-jun-2008, om 10:23 heeft Thomas Beale het volgende geschreven:

> I hope this clarifies things

Absolutely, thanks.

Stef

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

openEHR Querying specifications

[Stef Verlinden]

I'm not a technical person but to me it seems very cumbersome if such  
'differences' could exist between 2 versions of the same archetypes.  
This would mean that for every query one has to go into detail of  
every version of that AT which could mean al lot of work.

To my understanding versions of AT's should be 'backward compatible'.  
One can only add (and maybe remove) items, but never rename an  
existing item. Only then a lot of unnecessary work for 'query-makers'  
can be avoided.

Is this assumption indeed correct?

Cheers,

Stef

Op 3-jun-2008, om 23:26 heeft Mikael Nystr?m het volgende geschreven:

> I disagree with Rong.
>
>
>
> If for example the change between the first and second version is a  
> change in a position value set from ?sitting?, ?standing? and  
> ?other? to ?sitting?, ?standing?, ?lying? and ?other?. If then a  
> query is written for the first version of the archetype searching  
> for all cases where the position is ?not sitting? and ?not  
> standing? the query will search for the position ?other? and return  
> a correct answer.
>
>
>
> If we implement Rong?s suggestion the query will work also with the  
> second version of the archetype, but it will return another answer  
> than the intended, namely the cases where the position is ?not  
> sitting? and ?not standing? and ?not lying? instead of the intended  
> ?not sitting? and ?not standing?.
>
>
>
> I therefore think that excluding the version information can result  
> in a mess.
>
>
>
>   /Micke
>
>
>
>
>
> From: openehr-technical-bounces at openehr.org [mailto:openehr- 
> technical-bounces at openehr.org] On Behalf Of Rong Chen
> Sent: den 3 juni 2008 22:54
> To: For openEHR technical discussions
> Subject: Re: openEHR Querying specifications
>
>
>
> I suspect changes between version could potentially break the paths  
> in WHERE clause. So maybe the version information isn't significant  
> here since either the path works and the criteria are checked or  
> the path doesn't work and fails silently.
>
> /Rong
>
> On Tue, Jun 3, 2008 at 10:36 PM, Ian McNicoll  
>  wrote:
>
> Fair point. Perhaps AQL should support ranges of version numbers to
> simplify the query as in many cases the query will not be affected by
> a structrural change to the archetype
>
> e.g.
>
>
> > FROM EHR [ehr_id/value=$ehrUid]
>
> > CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v[BETWEEN  
> 1.5 AND 2]
> > CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v 
> [>=1]
>
> > WHERE (
> > obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/ 
> value >=
> > 140
>
> Versions and revisions would need to be handled.
>
> Ian
>
> 2008/6/3 Greg Caulton :
>
> >
> > --
> >
> > Message: 2
> > Date: Tue, 03 Jun 2008 16:39:37 +0100
> > From: Thomas Beale 
> > Subject: openEHR Querying specifications
> > To: Openehr-Technical 
> > Message-ID: <484565B9.6030805 at oceaninformatics.com>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> >
> > The current material is therefore intended as a resource for  
> discussion
> > and definition of a query language for openEHR. A team can be  
> defined
> > after sufficient time for the community to react to this material  
> and
> > determine if it makes sense to use AQL as the basis or to seek other
> > solutions or candidates.
> >
> > - thomas beale
> >
> >
> >
> > Perhaps this has been answered but as the archetypes change  
> version is it
> > expected that the AQL will need to keep up with that - I assume  
> our historic
> > data would be specific to the archetype version - not 'upgraded' ?
> >
> > i.e. after v1:
> >
> > FROM EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION
> > [openEHR-EHR-COMPOSITION.encounter.v1]
> > CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v1]
> > WHERE obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/ 
> value/value
> >>= 140
> >
> > after v2:
> >
> > FROM EHR [ehr_id/value=$ehrUid]
> > CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v1]
> > CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v2]
> > CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v1]
> > CONTAINS OBSERVATION obs2 [openEHR-EHR- 
> OBSERVATION.blood_pressure.v2]
> > WHERE (
> > obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/ 
> value >=
> > 140  OR
> >   obs2/data[at0001]/events[at0006]/data[at0003]/items 
> [at0004]/value/value
> >>= 140  )
> >
> > not sure if that is exactly right.
> >
> > thanks!
> >
> > Greg
> >
> >
> > http://www.patientos.org
>
> > ___
> > openEHR-technical mailing list
> > openEHR-technical at openehr.org
> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
> >
> >
>
>
>
> --
> Dr Ian McNicoll
> office +44(0)141 560 4657
> fax +44(0)141 560 4657
> mobile +44 (0)775 209 7859
> skype ianmcnicoll
>
> Consultant - Ocean Informatics ian.mcnicoll at oceaninf

MIE-2008

[Stef Verlinden]

Hi all,

Here's my positive reaction:-).

We started some discussion around this topic back in November. One of  
the other items we discussed then was a place for 'openEHR'  
presentations that could be used by others under a common creative  
(or other) license. Although I can find several presentations under  
'recently updated' I would expect those to be found under education.  
This might also be the place for the pages about the past, future and  
eventually the openEHR exclusive conference. Also this could be a  
place for all publications available. I know that publications can be  
reached directly form the home page under resources, but I think  
these should (also) be present in the Wiki section. The link directly  
under resources only reveals the 3 theses about workflow. There is  
another link under resources/ getting started and then under 'I want  
to - see the publication pages' (where probably the other  
publications could be found) but this link is dead. Having all this  
together under the educationsection in Wiki might provide an easier  
entrance for those who wants to be educated about openEHR.

Cheers,

Stef


Op 30-mei-2008, om 11:48 heeft Thomas Beale het volgende geschreven:

> Can we have reactions from a few more people - if the response is
> positive, I will organise the conference material onto the wiki.

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

{Disarmed} Comparison of EHR models

[Stef Verlinden]

Dear all,

Recently an article by Bernd Blobel was published in the Dutch HL7  
magazine (Dec 07 issue) in which he compares the different EHR  
models: openEHR, HL7v3, EN/ISO 13606 and CCR. Robert Stegwee, the  
chair of HL7.nl, kindly translates this article in Dutch, which  
unfortunately makes it unsuitable for distribution outside the  
Netherlands

I?ve tried to ask Bernd Blobel to share the original text of this  
article (which is hopefully in English), so that the openEHR  
community also can take notice of it. I haven?t received an answer yet.

I won?t translate the whole article back to English (and I still hope  
that Dr. Blobel will share the original article), but for the sake of  
discussion I would like already to point out a few things that  
?triggered? me.

 From what I understand Blobel claims that all the paradigms for an  
advanced EHR architecture were, already back in the nineties, defined  
in the context of the Generic Component Model (GCM) (no reference  
provided).
In the article he states that the GCM provides a service oriented,  
model driven system architecture for the development of a sustainable  
and semantic interoperable EHR systems.
The GCM provides a multi-model approach for EHR architectures, system  
development and implementations by the simplification of the system  
description by means of:
- transparent domain management,
- the composition and decomposition of the system components
- the views from the different angles on the system (amongst which  
thorough modelling of business models

As a result the GCM provides reference architecture for analysing,  
designing en implementation of EHR architectures, as well as a tool  
for the development of migration strategies (Educational challenges  
of health information systems? interoperability. B. Blobel, Methods  
Inf Med 2007; 46 p.52-56)

Although I can?t assess the article fully on it?s merits, the idea of  
a theoretical ?meta? reference architecture for the future which can  
be used for the purposes above seems appealing, both for further  
improvement of the openEHR architecture as well as for the future  
harmonisation of HL7 en openEHR in a common (EN/ISO 13606 derived?)  
internationally accepted EHR standard.

So my first question is: Is the GCM to be seen as a theoretical  
?meta? reference architecture, which can be used as a guideline for  
future developments? If the answer is no, why not?

Further in the article Blobel compares GEHR against the GCM. Although  
the header of this section mentions the openEHR foundation, he  
consistently talks about GEHR and the GEHR project  
(http:www.gehr.org). The URL for GEHR links to a site, which has to  
do with different aspects of healthcare than we?re generally talking  
aboutJ). Also when Blobel talks about ADL he refers to a URL that  
doesn?t exist anymore (http://www.deepthought.com.au/) and most  
certainly it wouldn?t have linked to the latest version of the ADL

So my second question is: is Blobel, when making his comparison,  
referring to the latest versions of the reference architecture and  
ADL as recently developed within the openEHR community?

Blobel?s conclusion of comparing GEHR to the GCM, is that GEHR limits  
itself to the structural aspects of the knowledge components and  
doesn?t comprise behavioural aspects. Also it isn?t possible, due to  
the lack of specified rules, to aggregate archetypes. Instead they  
have to be replaced by more complex archetypes.
More generally the GEHR approach has some essential shortcomings at  
the mathematical, system theoretical and informatics levels. These  
shortcomings have to be addressed in the future.

In the discussion en conclusion section Blobel adds to this: that  
within the EN/ISO 13606 approach, although almost complete as far as  
semantic interoperability concerns, a lot of shortcomings and  
inconsistencies have to be solved. As example: the issue of  
structural composition and decomposition, as well as the modelling of  
business processes is not solved well.

Personally I think that such statements should be underpinned with  
arguments/ scientific proof and/or examples or at least a reference  
to a properly peer reviewed article that does so. I would like to  
invite Blobel (and others if they feel obliged to) to provide these  
scientifically valid facts to underpin these statement, so we can  
have a proper discussion. This type of ?review? statements creates  
confusion, which hinders any serious discussion about future  
developments and harmonisation.  It also undermines the (in my  
opinion) otherwise good intention of the article as a whole.

My third and last question to the community is: are these conclusions  
(if applicable to the current version of openEHR) valid and if yes  
how can we address those issues?

Cheers,

Stef





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

Antw: Re: Antw: Re: Compact XML format...?

[Stef Verlinden]

Op 24-nov-2007, om 17:14 heeft b.cohen het volgende geschreven:

> No. A good standard should ensure that all implementations that  
> satisfy it are
> mutually interoperable (see, for example, the Whitworth stanard for  
> nuts and
> bolts!). This requires that:
> 1. the standard include the the tests that supposdly conformant  
> implementation
> must pass;
> 2. that test be necessary and sufficent to guarantee compliance; and
> 3. Proven compliance to the standard be necessary and sufficient to  
> guarantee
> interoperability.
I agree. I guess I should have written 'a good standard' should have  
only one version that is used by all who underwrite that standard. Of  
course it must comply to these 3 requirements above

> One way to do this is to for the standard to overdetermine  
> implementation to
> such an extent that exactly one implementation satisfy it. This is  
> how 'de
> facto standards' work.
> But I was of the impression that that was not the intention of the  
> international
> health care community. Am I wrong?
Can you please elaborate on this statement? My feeling is that your  
right but don't know what you mean exactly. As far as I know there  
are at least 3 different openEHR implementations on 3  different  
software platforms (Eiffel, .net and Java (and soon one on Ruby)),  
and these should be able to communicate seamlessly. So it seems that  
openEHR meets at least the first 2 the requirements and, if I'm  
correct, complying to the third is well on it's way

Cheers,

Stef

>
> Quoting Williamtfgoossen at cs.com:
>
>> In een bericht met de datum 24-11-2007 8:30:05 West-Europa  
>> (standaardtijd),
>> schrijft stef at vivici.nl:
>>
>>
>>> Op 24-nov-2007, om 7:45 heeft > HREF="mailto:Williamtfgoossen at cs.com">Williamtfgoossen at cs.com het
>> volgende
>>> geschreven:
>>>
>
>>>
>>>
>>> Can you, in this light explain what Barry Smith is talking about  
>>> in his
>>> HL7-watch blog (> HREF="http://hl7-watch.blogspot.com/";>http://hl7- 
>> watch.blogspot.com/, the
>> text is also underneath).
>>> Probably I don't understand it correctly, so if you could  
>>> enlighten me that
>>> would be very helpful.
>>>
>>>
>>> I think that we all agree that a good standard should have only one
>>> implementation
>>>
>>>
>>>
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>> Stef
>>>
>>
>> Hi Stef,
>>
>> Yes, here you have a point!
>>
>>
>> Sincerely yours,
>>
>> dr. William TF Goossen
>> director
>> Results 4 Care b.v.
>> De Stinse 15
>> 3823 VM Amersfoort
>> email: Results4Care at cs.com
>> phone + 31654614458
>> fax +3133 2570169
>> Dutch Chamber of Commerce number: 32121206  
>>
>
>
> -- 
> __
> Prof Bernard Cohen, Dept of Comp Sc, City Univ, Northampton Sq.
> London EC1V 0HB   tel: ++44-20-7040-8448 fax: ++44-20-7040-8587
> b.cohen at city.ac.uk  WWW: http://www.soi.city.ac.uk/~bernie
> "Patterns lively of the things rehearsed"
>
>
> 
> This message was sent using IMP, the Internet Messaging Program.
>
> ___
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical

Antw: Re: Compact XML format...?

[Stef Verlinden]

Op 24-nov-2007, om 7:45 heeft Williamtfgoossen at cs.com het volgende  
geschreven:

> V3 has no various implementations,

Can you, in this light explain what Barry Smith is talking about in  
his HL7-watch blog (http://hl7-watch.blogspot.com/, the text is also  
underneath). Probably I don't understand it correctly, so if you  
could enlighten me that would be very helpful.

I think that we all agree that a good standard should have only one  
implementation



Cheers,

Stef

---
  The Dialects of RIM

The latest Minutes of Evidence of the House of Commons Select  
Committee on Health, on the UK National Programme for IT, contain  
this comment from Richard Granger:

 In terms of the core Spine infrastructure, there was some  
mythology in the Health Informatics Community that the standards  
existed, HL7 was mature, and so forth. That was completely untrue.

Dr Granger goes on:

 We have had to put an awful lot of effort into specifying the  
standards for messages, around demographics, around booking, around  
prescriptions, and then the software that BT have built with a number  
of sub-contractors is brand new software that has been custom-built  
for the NHS; so that is high-risk, new build software. There was no  
other way of doing it. I am very pleased a number of other  
jurisdictions are getting very interested in using that.

He thereby inadvertently touches on another issue currently causing  
concern in HL7 circles. The HL7 Reference Information Model or 'RIM'  
was, we will remember, introduced as the solution to the problems  
created by the appearance of multiple dialects in earlier versions of  
the HL7 standard. HL7 would prevent the appearance of dialect  
versions by enforcing conformity to the RIM. Now, however, it is  
becoming increasingly clear that the RIM itself exists in multiple  
dialects.

This is more than just a problem of successive, incremental  
improvements. As the RIM Document Editorial Assessment from 8 June  
2007 points out:

 ... the 2006 Normative Edition contains a RIM document based on  
the last balloted RIM [from 2003]: this gap creates the opportunity  
for conceptual conflict between the document and current practice. A  
reader must choose between a normative edition of the RIM published  
for ANSI, which contains nothing extraneous but is out of date; an  
extract of the current RIM as maintained by MnM, which will be the  
most up-to-date, but which is not readily available to the membership  
at large; or, which is most probable, the RIM document published in  
the Normative Edition, which both contains extraneous information and  
is out of date.

It seems, in fact, that we have at least:

1. the version of the RIM adopted by ISO as an international standard

2. the balloted RIM document that describes those parts of the RIM  
designated as 'normative', the latest (and still current) version of  
which, it seems, dates back to June 2003

3. an ANSI publication based on 2.

4. a CEN Standard EN 14822-1:2005 Health informatics - General  
purpose information components - Part 1: Overview (see also CEN  
Standard EN 14720-1:2005), based on 3.

5. the 'living' RIM UML model (regularly updated through  
harmonization) as it exists at any given stage. This RIM contains  
content that existed at the time of balloting in 2003 but was not  
then balloted, together with four years worth of cumulated changes.  
Some of this material is, I am told, intended to be balloted in the  
future; some (e.g. in CoreInfrastructure subject area) is not.

6. an idealized 'frozen' version consisting of those parts of 5.  
which have, at any given stage, passed through the process of  
harmonization,

7. the UK rebuild.

As I understand matters (and as always this understanding may be for  
various reasons imperfect) the RIM documentation included in any  
publication of the V3 standard more recent than 2003 should be based  
on the latest working version of the model as maintained by the  
Modeling and Methodology (MnM) committee. The publication label  
?Normative Edition? may cause confusion, however, if it is taken by  
the reader as suggesting that the contents so labeled are all  
normative (though this issue should be addressed in the relevant  
document preface).
-- next part --
An HTML attachment was scrubbed...
URL: 

Multiple parents and max number of nested specialized archetypes?

[Stef Verlinden]

>>
> ah - 'data quality' in other words - i.e. markers / meta-data relating
> to the data capture from the source, not the integrity of the data as
> represented on the openEHR system?

I would like to expand that to data quality assurance. How can one  
objectively and according to locally accepted standards establish  
that data is of good quality, i.e. (re)usable, or should be rejected/  
ignored. IMHO this is one of the crucial points for a functional EHR.  
What's the use of a centralized system to store and retrieve  
semantically interoperable data if the data is of poor/unknown  
quality. It also has a legal aspect. When one uses data provided by a  
third party one also takes over/ shares responsibility from/with that  
third party if one willingly accept data of poor quality. My guess is  
that not many people want to do that.

Cheers,

Stef

Multiple parents and max number of nested specialized archetypes?

[Stef Verlinden]

I agree with Heather, this is the way to go if one wants to  
accomplish maximal interoperability and queryability. We should as  
much as possible try to avoid multiple archetypes for the same  
knowledge domain because it will restrict exchangeability of data

Cheers,

Stef


Op 18-okt-2007, om 11:24 heeft Heather Leslie het volgende geschreven:

> My approach would is in synch with Sebastian - ideally one maximum  
> data set
> of all content for one pap archetype, from any source or standard,  
> then
> constrained in a template for Bethesda's purposes, NHS' needs etc.   
> Then the
> data has maximal interoperability and queryability.
>
> In this case you wouldn't need multiple inheritance - I think the  
> key is in
> the 'art' of the design of the initial and maximal pap archetype.
>
> Heather
>
>> -Original Message-
>> From: openehr-technical-bounces at openehr.org [mailto:openehr- 
>> technical-
>> bounces at openehr.org] On Behalf Of Sebastian Garde
>> Sent: Thursday, 18 October 2007 8:46 AM
>> To: For openEHR technical discussions
>> Subject: RE: Multiple parents and max number of nested specialized
> archetypes?
>>
>> Hi,
>>
>> I also think we should avoid multiple inheritance - it is complex  
>> enough
>> the way it is - from a tooling as well as from an archetype design  
>> point
>> of view. We don't need to make it complicated in addition to complex.
>>
>> Like Erik, I don't know the details of these two archetypes, but I  
>> think
>> a better design than using multiple inheritance would be to
>> - use a common base archetype for both. Here everything that the two
>> archetypes have in common (even if it is a little bit more generic  
>> than
>> it would be when only considering one of them) can be located. And  
>> also
>> everything that doesn't largely overlap can be located as optional  
>> items
>> - even if it doesn't have any relevance to the NHS and or Bethesda.
>> - If really necessary specialise this base archetype for the
>> environment, but preferably use templates to achieve this (strip out
>> unnecessary items in your environment, further constrain the  
>> archetype
>> etc.)
>>
>> Cheers
>> Sebastian
>>
>>> -Original Message-
>>> From: Erik Sundvall [mailto:erisu at imt.liu.se]
>>> Sent: Thursday, 18 October 2007 5:04 PM
>>> To: For openEHR technical discussions
>>> Subject: Re: Multiple parents and max number of nested specialized
>>> archetypes?
>>>
>>> Hi!
>>>
>>> Interesting discussion. I'm hope we can avoid multiple  
>>> inheritance in
>>> archetype specialisation. It will be interesting to see how far one
>>> can get just using single inheritance and inclusion (clusters etc).
>>>
>>> On 10/17/07, Koray Atalag  wrote:
 There are now two alternative archetypes, one designed for NHS by
>> Ocean
>>> which
 is already a specialization of general histology archetype and the
>> other
>>> archetype
 I am currently modeling, Bethesda System 2001. I have not
>> experimented
>>> yet if
 my archetype can be redesigned as a specialization of NHS archetype
>>> (PAP)
 or be a an alternative archetype for the same purpose possibly for
>> use
>>> at a different
 setting. In the case of having two separate alternative archetypes,
>> I
>>> thought of
 having a further specialized archetype which conforms to both
>> parents. I
>>> think
 this is possible and useful.
>>>
>>> What is different and what is in common in the two 'smear' archetype
>>> approaches (Bethesda v.s. NHS)? Sorry if this is a stupid question
>>> coming from a non-clinician.
>>>
>>> Does the reasoning in the paper...
>>>
>> http://www.openehr.org/publications/archetypes/ 
>> templates_and_archetypes_
>> he
>>> ard_et_al.pdf
>>> ...regarding organisational vs ontological models apply to this  
>>> or are
>>> the differences of another nature?
>>>
>>> Can one share important sub-parts without sharing view on process  
>>> and
>>> structure. If so, will the information entered using the two  
>>> different
>>> archetypes be computable in a similar way for e.g. decision support
>>> systems.
>>>
>>> Perhaps the best will be to agree on one archetype in this case if
>>> possible, but I assume similar cases will surface again. From a
>>> technical perspective it is interesting to discuss how far one  
>>> can get
>>> in reaching clinical consensus in 'ontological' sub parts. Splitting
>>> things up in too many small 'consensus pieces' without sharing
>>> encompassing structure is also likely to have negative impact on
>>> semantic interoperability.
>>>
>>> Best regards,
>>> Erik Sundvall
>>> erisu at imt.liu.sehttp://www.imt.liu.se/~erisu/Tel:
>> +46-13-227579
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical at openehr.org
>>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>
>> ___
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org

Hidden reference model stuff in template

[Stef Verlinden]

Hi Thio,

Thanks for this excellent explanation. Although it remains a steep  
learning curve for a 'non-technical' person, it certainly provides a  
better insight in this 'tough' material.

One last remark to explain my question. I while ago Thomas Beale  
demonstrated the OI template builder, which is a really great tool.  
 From what I understood this template builder also can be used as a  
GUI designer and that's where my interest lies. Thing is that  
templates, as you stated, further constrain and bundle several  
archetypes to fit a certain organisations data entry needs.
My point is that since the 'hidden classes' aren't present in the  
originating archetype(s), there also aren't present in a GUI  
constructed with this template builder. Therefore such a GUI lacks  
certain 'essential' data entry classes/fields (for instance 'date and  
time of measurement).
You can also see this in the 'example templates' made for/by the NHS- 
UK and which can be found in the dev-uk-nhs part of the archetype   
database.
So if you look for instance at the 'bloodpressure template (Archetype  
Id openEHR-EHR-OBSERVATION.blood_pressure.v1 Template ID945c2617- 
dc89-4c28-94cf-43ee46c1ecb0), you'll only see the data classes/fields  
which where archetyped but none of the 'hidden' data classes/field  
(such date/time of measurement but also performer of committer).  
These are typical examples of data I would like to present in and/or  
enter via a GUI. So I guess a template builder isn't suitable for  
creating GUI's after all (or I've misunderstood this in the first  
place).

Thanks again,

Stef

Op 31-mei-2007, om 1:50 heeft Thilo Schuler het volgende geschreven:

> Hi Stef,
>
> I have followed the thread and I will try to provide some hopefully
> useful hints. I will start with the central idea, the
> two-model-approach, and will try to cover your questions after that:
>
> - Archetypes are a way of constraining and "plug-and-playing" (LEGO
> principle) a relatively limited number of generic reference model
> classes of the reference model, that are expected to stay stable over
> a long period of time.
> In that way the multitude of quickly changing medical concepts (the
> medical knowledge) can be expressed and adapted to the current needs,
> while the building blocks (the reference model classes) stay the same.
> One big advantage of this approach is that software can be developed
> based on the reference model without knowing the archetypes in advance
> (future proof systems).
>
> - Analogy: Reference model classes are the LEGO bricks, Archetypes are
> the LEGO construction plans
>
> - The constraining rules ("grammar") of *all* archetypes (or more
> precisely archetype instances) are defined in the archetype model.
> That is where the name two-model-approach came from: firstly the
> reference model and secondly the archetype model.
>
> - Every archetype (e.g. for blood pressure) is an instance of the
> archetype model.
> There could be many notations invented to express this archetype
> model. They only have to support the full semantics of the archetype
> model. Of all the theoretically possible notations the archetype
> editor currently supports ADL and can also transform the archetype
> into an XML version.
>
> - Every piece of medical information (the blood pressure values of
> person X in simple case) is a "bundle" of several reference class
> instances with the attributes set to certain values (to reflect the
> state of the patient X). The archetype or a combination of archetypes
> define(s) which classes, how many of them and what combination are in
> the bundle. Further more it can define things like value ranges for
> reference class attributes. Like archetyeps hese bundles could also be
> expressed in several formats, but today mostly XML is used (this is
> meant when Sam talks about data).
>
> - So don't confuse an XML data "bundle" (validated by the reference
> model schema) with an archetype expressed in XML.
> - In a message etc you would send the XML data NOT (!) the XML
> archetype that the archetype editor can output. Although there are
> references to the archetypes (that where used during creating) in the
> data. So the receiving system of the message can also retrieve the
> archetypes from an archetype server to add meaning to the data.
>
> - An archetype can validate (during creation or after reception) that
> a data bundle conforms to the concept that the archetype describes. So
> an archetype is a "schema" of a particular medical concept. Actually
> the XML schema language was evaluated as a means of expressing
> archetypes but was found to be not expressive enough. Therefore ADL
> has been invented.
>
> - As it was mentioned before (and as you correctly named "hidden"
> reference model stuff) archetypes only contain the constraints on the
> reference model which FURTHER constrain what is "automatically" by the
> reference modle. So if the a reference model
> class has an attrib

Hidden reference model stuff in template

[Stef Verlinden]

Maybe this question should be asked on the technical mailing list,  
since there's no reaction on the clinical list:-)

Cheers,

Stef

Begin doorgestuurd bericht:
Van: Stef Verlinden 
Datum: 24 mei 2007 12:00:43 GMT+02:00
Aan: For openEHR clinical discussions 
Onderwerp: Antw.: Point in time 2

Great. Does this also mean that this 'hidden' reference model stuff  
will/can be a part of a template? From my point of view I would like  
to 'control' (view and/or enter) thing as date/time of measurement  
via a template.

Another question related to that.  The way I think to understand it  
(as a non-technical person:-) ) we can use the XML message's created  
by the archetype editor to display and post data to and from a UI/ 
website.
But here again, this XML message comprises only the classes that are  
created in the archetype but not the 'hidden' stuff.
Is there an 'overhead' XML message in which the 'specific' AT XML  
message can be embedded/nested so one has access to all available data?

Cheers,

Stef


Op 23-mei-2007, om 7:01 heeft Thomas Beale het volgende geschreven:

Erik Sundvall wrote:
Hi!

On 5/22/07, Heather Leslie  wrote:

Perhaps the apparently 'hidden' reference model stuff should perhaps
even be displayed, in an uneditable format, in the Archetype Editor and
Template Designer - to make this design process more transparent and
help bridge the clinical/technical divide just a little.


This very much matches my point of view. Ideally archetype editors etc
should be delivered with a built in mini-EHR system for simple testing
purposes (security, scalability etc would not be in focus then). I
think such a solution will come from somewhere eventually. I'd love
provide something like that in the LiU Archetype Editor. I wish we had
enough time and resources to implement that, currently we have to
focus on other more urgent things. We do have engineering students
doing master thesis work around openEHR-based GUIs though and with
some luck that might provide some parts of the suggested solution.

I agree that we need this kind of functionality; it will be implemented
fairly soon in the ADL workbench and Archetype Editor.

- thomas


___
openEHR-clinical mailing list
openEHR-clinical at openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical


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