Why is the editor not opening ADL files?

Dear all,

I am browsing through the existing archetypes from Ocean, obviously created by the Ocean Archetype Editor given the file name.

E.g.

openehr-demographic-person.person.draft.adl

When I try to open it with the AE, I do get continuously error messages similar to:

Is there anything wrong with the archetypes, or is this an error in the archetype editor.

Anyone els experiencing such problems?

Sincerely yours,

dr. William TF Goossen
director
Results 4 Care b.v.
De Stinse 15
3823 VM Amersfoort
the Netherlands
emails:
Results4Care@cs.com
williamtfgoossen@cs.com
info@results4care.nl

phone + 31654614458
fax +3133 2570169
www.results4care.nl
Dutch Chamber of Commerce number: 32133713

As far as I know, Ocean archetype editor does not support openEHR
demographic archetypes

Hi William,

The current version of the archetype editor does not support Demographics archetypes. These archetypes were created manually in raw Adl. I am working on an update to the Editor to support Demographics archetypes but this is still some weeks away from completion.

Ian

Dr Ian McNicoll
Clinical analyst Ocean Informatics
Tel/fax +44(0)141 560 4657
Mobile +44 (0) 775 209 7859
Skype imcnicoll

Thanks!

Sincerely yours,

dr. William TF Goossen
director
Results 4 Care b.v.
De Stinse 15
3823 VM Amersfoort
the Netherlands
emails:
Results4Care@cs.com
williamtfgoossen@cs.com
info@results4care.nl

phone + 31654614458
fax +3133 2570169
www.results4care.nl
Dutch Chamber of Commerce number: 32133713

How many more types of archetypes are we envisioning to support?

Hopefully the Java ADL parser does not need to change - a new XML schema does not require a new XM Lparser.

In a message dated 14-3-2009 17:23:18 W. Europe Standard Time, caultonpos@gmail.com writes:

How many more types of archetypes are we envisioning to support?

I think the tools need to support ANY archetype that represents valid content in health care.

Sincerely yours,

dr. William TF Goossen
director
Results 4 Care b.v.
De Stinse 15
3823 VM Amersfoort
the Netherlands
emails:
Results4Care@cs.com
williamtfgoossen@cs.com
info@results4care.nl

phone + 31654614458
fax +3133 2570169
www.results4care.nl
Dutch Chamber of Commerce number: 32133713

Williamtfgoossen@cs.com schreef:

In a message dated 14-3-2009 17:23:18 W. Europe Standard Time, caultonpos@gmail.com writes:

How many more types of archetypes are we envisioning to support?

I think the tools need to support ANY archetype that represents valid content in health care.

An archetype editor should simply support any archetype which represents a valid locatable according to the reference model, plus, it must adapt the other archetype-rules as defined in the reference model, such as header requirements, etc.

Bert

Williamtfgoossen@cs.com schreef:

In a message dated 14-3-2009 17:23:18 W. Europe Standard Time, caultonpos@gmail.com writes:

How many more types of archetypes are we envisioning to support?

I think the tools need to support ANY archetype that represents valid content in health care.

An archetype editor should simply support any archetype which represents a valid locatable according to the reference model, plus, it must adapt the other archetype-rules as defined in the reference model, such as header requirements, etc.
That is why I don’t understand the trouble with supporting demographic archetypes, it are just locatables, with a few extra characteristics, but that is also the case for composition or other archetypes. It are all just locatables.
Maybe some one can explain this.

In a few months, I will have more time, I will add the support myself, I even install Windows, if necessary.
Maybe I find out by then what I have overlooked all the time.

Bert

William,

When you say "browsing existing archetypes from Ocean", where exactly are
you browsing?

Heath

Bert,

The Ocean Archetype Editor was the first Archetype Editor written some 6+ years ago. It was implemented to support only EHR archetypes in a way that these RM types where implemented explicitly within the Editor providing the specific capability for clinicians to easily develop archetypes with minimal knowledge of the RM.

Certainly a generic archetype editor would need to support the features you suggest below, but the Ocean Archetype Editor is not a generic Archetype Editor. Even with its limitations known best by Ocean, I think we can all agree that it has served the openEHR community well in bringing the mind shifting concepts of archetypes to a point where the openEHR architecture is in demand internationally.

Regards

Heath

I got these examples in 2007 from the OpenEHR list.
This is the one I was working with

Sincerely yours,

dr. William TF Goossen
director
Results 4 Care b.v.
De Stinse 15
3823 VM Amersfoort
the Netherlands
emails:
Results4Care@cs.com
williamtfgoossen@cs.com
info@results4care.nl

phone + 31654614458
fax +3133 2570169
www.results4care.nl
Dutch Chamber of Commerce number: 32133713

(attachments)

openehr-demographic-person.person.draft.adl (13 KB)

Hi William

I think this may have been answered elsewhere. The reference model for this archetype is the openEHR demographic model and it is starting to get some interest. It is still a research work in progress. These archetypes where hand built to illustrate ADL working with another model. There are also some v3 RIM archetypes as well.

Cheers, Sam

Hi Bert and all

The demographic model was proposed a long time ago and is meant to support a demographic service – like a PMI. These archetypes are not in the EHR. The EHR and demographic service can share archetypes like data_structures, clusters and elements and for this reason it is worth aligning them.

The Ocean archetype editor was built before ADL and works by using the ADL parser and XML parser. The reference model is hard coded as a class. TO work with another reference model it is necessary at the moment to hard code another class. A generic approach to this is possible and may in time be useable.

In the meantime, I just want to be clear that the demographic model archetypes cannot be used in the EHR – they are not relevant there.

Cheers, Sam

Heath Frankel schreef:

Bert,

The Ocean Archetype Editor was the first Archetype Editor written some 6+ years ago. It was implemented to support only EHR archetypes in a way that these RM types where implemented explicitly within the Editor providing the specific capability for clinicians to easily develop archetypes with minimal knowledge of the RM.

Certainly a generic archetype editor would need to support the features you suggest below, but the Ocean Archetype Editor is not a generic Archetype Editor. Even with its limitations known best by Ocean, I think we can all agree that it has served the openEHR community well in bringing the mind shifting concepts of archetypes to a point where the openEHR architecture is in demand internationally.

There is no doubt about that it did serve many people. Please do not see my comments as criticism. I was really wondering. Now I read your message, I understand a bit better.
I think/understand it was even more work to limit the AE to serve people with minimal knowledge of the RM than to build a generic one.

I think, to build a generic AE is not that difficult, and can be done in a few weeks by an experienced programmer. There is a lot of recursively in code possible. The point where things gets a bit more difficult is at the end nodes where datatypes have to be constructed and valided, but then again, there is a lot of example code in Java and VB, and one can profit from the inheritance-schemes of the datatype part of the RM.
Live-connection to terminology would maybe be a bit more difficult, but it can be a good tool without that.

It would be a nice project to do, not to hard, and very useful.

Maybe later, when I have time, I will build one.

Bert

Sam Heard schreef:

Hi Bert and all

The demographic model was proposed a long time ago and is meant to support a demographic service – like a PMI. These archetypes are not in the EHR. The EHR and demographic service can share archetypes like data_structures, clusters and elements and for this reason it is worth aligning them.

The Ocean archetype editor was built before ADL and works by using the ADL parser and XML parser. The reference model is hard coded as a class. TO work with another reference model it is necessary at the moment to hard code another class. A generic approach to this is possible and may in time be useable.

Thanks for explaining. In my previous message, (before reading this one), I went already into this subject.

It is also clear, in my opinion that Ocean has no obligation at all to build any tool. It cost time and money to do so. And the community must be grateful for what it gets. Me, I am. There work of ocean (and many others) give me a wonderful business opportunity.

So, if the community misses demographic archetypes-editor, it is free to build one, which I said, is not to hard for an experienced programmer, and it can be done in almost any programming language, even in a Word-macro, however, it is not the choise I would make.

In the meantime, I just want to be clear that the demographic model archetypes cannot be used in the EHR – they are not relevant there.

I don’t understand what you mean here. In the EHR-Status is a PartyRef (http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140537614753_438721_176Report.html) to connect the EHR to a Party (which is a demographic object, and thus need a demographic archetype. But maybe I misunderstand what you say.

Bert

I am confused - hopefully you saying that those particular ‘older’ demographic models are not supported?

But there are newer ones right being added to the CKM that conform to the ADL structure the other clinical ADLs use?

You are not saying an AQL query for

Women over 50 - 70, last mammogram > 2 years

cannot be supported because demographics are not relevant?

Greg Caulton wrote:

I am confused - hopefully you saying that those particular 'older'
demographic models are not supported?

But there are newer ones right being added to the CKM that conform to
the ADL structure the other clinical ADLs use?

Hi Greg,

the new ones, based on ISO 22220, made by Rigoleta Dutra and Sergio
Freire in Brazil will replace any of those early ones. I think they are
still messing around with them a bit before putting them on CKM.
Initially, they don't have a GUI editor tool, and have to be edited by
hand in ADL (one of the reasons we took the trouble to make sure ADL was
human-readable).

You are not saying an AQL query for

Women over 50 - 70, last mammogram > 2 years

cannot be supported because demographics are not relevant?

it already can, regardless of demographics, because such clinically
relevant data as date of birth and sex are recorded in the EHR anyway -
you would not attempt to do a join across EHR and demographic services
to answer that query. Although, if you had a service more oriented to
demographics + admin events, you could potentially satisfy this query on
it; however, in general, clinical queries will refer to a mixture of
basic data like age, sex, maybe occupation (where relevant to health)
etc, as well as the 'hard' clinical data; they would normally be run on
an EHR containing this data.

- thomas beale

Sam,

this below - demographics not relevant in the EHR is like the most confusing comment ever I heard from you.

About whom are we going to create a EHR then? If it is not possible to have the individuals name, id, birthdate and sex in the EHR (generally named patient demographics), it becomes useless in my vue.

Or do I miss a point here?

William

In a message dated 16-3-2009 8:39:20 W. Europe Standard Time, sam.heard@oceaninformatics.com writes:

In the meantime, I just want to be clear that the demographic model archetypes cannot be used in the EHR – they are not relevant there.

Cheers, Sam

Sincerely yours,

dr. William TF Goossen
director
Results 4 Care b.v.
De Stinse 15
3823 VM Amersfoort
the Netherlands
emails:
Results4Care@cs.com
williamtfgoossen@cs.com
info@results4care.nl

phone + 31654614458
fax +3133 2570169
www.results4care.nl
Dutch Chamber of Commerce number: 32133713

Caution; a bit of a rant ahead....

it already can, regardless of demographics, because such clinically
relevant data as date of birth and sex are recorded in the EHR anyway -
you would not attempt to do a join across EHR and demographic services
to answer that query. Although, if you had a service more oriented to
demographics + admin events, you could potentially satisfy this query on
it; however, in general, clinical queries will refer to a mixture of
basic data like age, sex, maybe occupation (where relevant to health)
etc, as well as the 'hard' clinical data; they would normally be run on
an EHR containing this data.

Maybe I should ask a question first. Are we building a model JUST for
personal healthcare; or for general healthcare?

I ask this because I get the impression from Thomas' statement (and the
overall all direction of archetypes. That the mind set is that
healthcare information is ONLY personal.

In fact healthcare involves us and everything around us. Our living
spaces, our working spaces, the people that we come into contact with.
We cannot separate our health events from our environment (geographical
or social). I thought that I was aware of this when I lived in the US,
Canada, Sweden and studied in the UK. However, living and working in a
developing country for one year now has made me realize just how
industrialized and general practice oriented the archetypes are for
openEHR. I sincerely believe that the RM is in good shape (okay we
(OSHIP) plan to bring on some bio-informaticians and that may change
things in the RM just a bit).

While as an American I love the ability built into the openEHR model to
separate demographics from clinical; in the real (larger) world, in many
cases, that demographic information is CRUCIAL to healthcare systems to
see what is happening in a region.

I was the first one to complain (to Sergio) that Rigoleta's archetypes
didn't comply with the RM (I couldn't implement them). I should have
been complaining to the ARB that we were not ISO 22220 compliant???

I am as remiss as everyone else in not filing CR's so that these changes
can go through the proper channels and be decided and changed. openEHR
has a wonderfully organized change manangement system. We should all
use it.

<my rant for today> Stay tuned for tomorrow's rant on why climate change
is evolutionary. :slight_smile:

Cheers,
Tim

....now back to making the Python archetype builder actually build
archetype instances......

Hmm. I can see why some groups might want to limit the scope of
their applications to EHR pure clinical, research type usage that ONLY
had clinically relevant demographic data.

But I don't think OpenEHR as a whole should have that scope limitation.

Nor do I think it does, to date the archetypes have shown to be quite
flexible in modeling a variety of data.

If Oceans direction is not to tackle hospital administrative and
demographic data which is critical to EMR type applications which run
in a live, working system then I totally understand that - you have
limited resources and have already done so very much.

This might explain (ahem) the delay in getting demographics online.

But what is more concerning to me is that we have a new set of ADLs
that are using a new structure that is not compatible with the current
set of editors. Bert said he might have overlooked something, I never
looked in order to overlook - I took for granted that the ADL
structure was already maximally defined and that any demographic or
administrative data would fit into this structure.

Having looked at new the new demographics they cover demographics and
not general administrative data typical to most HL7 interfaces.

I have not ruled out create the archetypes ourselves but I don't have
enough resources today.

Our system can support many coding systems but I would have like to
understand if OpenEHR leadership are going to support the broader
needs of the community - and we recognize they need resources to do
that - it cannot fall on Oceans shoulders - but at the same time if
CKM becomes the preferred tool we should organize accordingly.