Why is the editor not opening ADL files?

Clinical (archive)
21

Williamtfgoossen@cs.com wrote:

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?

Hi William,

yes, in fact, what he meant was that the more comprehensive demographic
information modelled by the openEHR demographic model is not directly in
the EHR, it is in dempgraphic information objects, which would typically
be in their own service - particularly in Europe where legislation
largely requires this to be the case. This does not of course mean that
demographic information of clinical significance would not be in the
EHR, e.g. date of birth, sex, occupation etc. The archetypes that would
model these elements are based on the EHR part of the RM, not the PARTY
and related classes from the demographic part of the RM.

- thomas beale

22

Hi,

I agree, specially if we think of OpenEHR as a PATIENT CENTRIC specification of an EHR.

Cheers,
Pablo.

23

Thomas Beale schreef:

24

Hi Greg

No – we are not on the same page yet. Let me go back a step.

The demographic service (patient look up, address, date of birth etc) is usually already existing when we add an EHR service. For this reason openEHR, although it has a demographic model, has not had pressure to implement it. The archetypes that you found on the openEHR site were built by hand to demonstrate the application of ADL to another reference model (you will find HL7 RIM archetypes as well).

Archetypes are specific to a reference model class – and the demographic and EHR models are not the same (but data structures, clusters, elements are shared by both). So it is possible to share cluster archetypes in the EHR and demographic environments.

So archetypes of PARTY in the demographics area cannot be used in the EHR – but a cluster for name or address can be.

Does that make sense now?

The newer ones under the person icon in CKM conform to the demographic model . These have been created in Brazil.

There are cluster archetypes that also have demographic features – which can be stored in the EHR (remember that the EHR model and Demographic model share the cluster class.

I hope that helps – Sam

25

Hi William

We are taking a service oriented approach here and it has benefits. You can store demographics in the EHR if you like and there are archetypes to allow for this. But generally this data is stored elsewhere in real systems. It is used for administration, billing and a lot of other things. Many hospital have large systems before they implement the EHR.

So the EHR as a service can exist without recording the demographic information in the EHR itself. In France it is illegal to do so – requiring separate security to get access to demographic and personal health information.

In our environment, the EhrGate component manages the interface to the demographic service – allowing demographics to be returned in queries and for accountability etc. This could be from an openEHR demographic service if that was suitable for that environment – or any other demographic system.

Finally, any information between systems is sent as an extract. This brings together the demographic and personal health information for transport, production of a CDA or whatever is required.

I hope this helps. It might not seem intuitive but it is very practicle and a result of a lot of companies being involved in the architecture design (all with different demographic services and requirements).

Cheers, Sam

26

Sam, I often brought this subject up, maybe five times last year, the answer differed from, “We’ll add demographic archetypes to the ArchetypeEditor within a year” to now carefully stating in a direction that demographic archetypes will loose the relevance. I know Sam, the latter is your position for longer time.
I believe, we have to distinguish the position of Ocean as a company, and the definition of openEHR as a worldwide concept/standard.
As I said before, I don’t think that Ocean should add demographic archetypes to their tooling. It would be nice if they do so, but that is their choice. They are a company, and have their own priorities.

You are addressing WIlliam in this message, but it is a message on a public mailinglist. I see your message as indirectly addressed to the community. So I am not answering for William, I am answering on my own behalf.

I am building software based on openEHR, and I also have to deal with these questions and positions.
It is very easy to build a demographic service based on archetypes and RM. I have done that. So I have a need for demographic archetypes.
It is also very well possible to connect a demographic service which is not based on OpenEHR. My customers have a choice.
It is also possible to use messages of al kind, and archetypes based on the message structures to import demographic data, this is very useful for organisations which want to migrate to an openEHR system.
This is possible because of the design of flexibility in the archetypes-concept.

The interface/API I created has only the possibility to import demographic data based on archetypes, and to recognize these data as being demographic and therefore to store that in the demographic service, without any extra programming effort.
If a customer has a demograpic service that is not based on OpenEHR, it probably publishes its own API to be used.
So, in my API I am only dealing with demographic data based on OpenEHR/archetypes.
I can, if the customer wants, cosmetically integrate his demographic-service API (if it is not based on OpenEHR) in my own API, so it looks like a single interface to be used.
In that case, there will be no demographic archetypes be needed in the system, in that case my system does not process demographic data, only references them.

OpenEHR is scaleable, that is one of its powers. Scaleable means, it can fit to small scales too. In small environments, there may be a need for a locally demographic service.
What is also important. OpenEHR has done a lot of effort to be flexible, to fit in as many health inforation system-requirements as possible, even in requirements which are not yet defined. Or which are defined in a far away country of which we haven’t thought yet.
It is not said that laws anywhere in the world will allow demographic data to be centralized and shared.
In the Netherlands, at this moment, 300.000 people choose not to be added to a national health information system. This number is expected to grow when the national healthcare system becomes a fact.
This means that demographic data will stay locally on the healthcare sites, for example, a GP, a dentist, a hospital. This means, the Dutch systems tolerates contradictory demographic data. The dentist may not know that you are married, if you don’t want him to know that. It is a design choice based on what people want. The people in the Netherlands have a possibility to opt out of the national healthcare system.
OpenEHR must facilitate that, and it does. It can run with integrated demograpic data, or separate demographic service, being based or not based on openEHR. Very flexible.

Regarding to OpenEHR itself.
It is technically possible to remove the demographic section complete, because, in fact, the demographic rm-classes are no more than datastructures with a special typename which indicates being demographic. One could conclude that they are, for that reason superfluous.
But there are advantages to having a demographic section, f.e. a future possibility to make changes to the demographic RM-part part only.
An other advantage is that there is a way to technical distinguish if a RM-datatructure contains demographic data, in this way helping to avoid to blur the demographic service concept, and let slip demographic-data into the EHR-data.

Bert

Sam Heard schreef:

27

Hi Bert,

Just for clarification, the work I have been doing in adding
demographics archetype support to the Ocean Editor is a personal
project, intended for the openEHR community and not an Ocean funded or
directed project. This was largely to help me understand the inner
workings of the Editor and for my own education, but I was aware that
there has been increasing interest in the wider openEHR community in
the Demographics model e.g. the work done in Brazil and the original
query by William. This is not a high priority piece of work for me and
will take some time to complete . When the code is a little more
stable I will put it up on Subversion as a Branch on the Archetype
Editor project

I must confess to being a bit surprised by the amount of heat that
this topic has generated!!

Demographics are, of course, a crucial aspect of any EHR and the
openEHR Demographics model provides a very elegant set of base classes
on which to base archetypes for the key concepts of party, role,
contacts , addresses etc. These are referenced from the main 'EHR
model' via 'party_refs' which adds a layer of confidentiality to the
EHR data and allows other demographics models to be used instead.

As Sam has explained, and I think you have agreed, the complexity and
variety of pre-existing national and vendor demographics models makes
it unlikely that the openEHR Demographics model will be a priority
area in the near future but may find favour in completely new EHR
developments.

For me this was simply an opportunity to delve a little deeper into
the technical aspects of openEHR, hopefully making a small
contribution to the open source base, without tripping up too much on
mainstream EHR model developments.

It should be noted that the Demographics Model restricts itself to
very 'pure' demographics i.e. person and other party identifiers and
contact details, as would be expected in a patient register. Anything
else e.g Housing details, language requirements etc should be modelled
in the EHR Model (though again, in reality, there may be some local
variation in implementation.)

Cheers,

Ian

Ian

Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian@mcmi.co.uk

Clinical Analyst Ocean Informatics ian.mcnicoll@oceaninformatics.com
BCS Primary Health Care Specialist Group www.phcsg.org

28

Ian McNicoll schreef:

Hi Bert,

Just for clarification, the work I have been doing in adding
demographics archetype support to the Ocean Editor is a personal
project, intended for the openEHR community and not an Ocean funded or

Thanks Ian, for your reply.

I didn’t know that the ArchetyoeEditor supports demograpic archetypes.
I answered to the complain from William that it did not, and others confirming this.
I knew it did not support demographic archetypes a sometime ago.

And thus, I am surprised to hear from you that you are adding support for demographic archetypes. Which is good news.

Me, for myself, getting tired of this issue, started a few days ago withn diving into the sourcecode of the LiU Archetype-Editor.
But it cost hours only to get the project compiling, because the code is not maintained for some time, and things on which it depends have changed.
And time really is a problem, I can only work one or two hours in the evening on this.

directed project. This was largely to help me understand the inner
workings of the Editor and for my own education, but I was aware that
there has been increasing interest in the wider openEHR community in
the Demographics model e.g. the work done in Brazil and the original
query by William. This is not a high priority piece of work for me and
will take some time to complete . When the code is a little more
stable I will put it up on Subversion as a Branch on the Archetype
Editor project

This is a very good idea, it not only serves the possibility for people to use it, but also, and that is important, it helps creating the eco-system around OpenEhr, which is necessary to make the concept a success.
It is for some people surprising that the support for demographics is not in the ecosystem.

And what people put in the demographic session, it is up to them, OpenEhr offers flexibility, that is its power.
There are discussions about that, often on the list. I do not participate often, because, I want to be a system-builder of a flexible system. Let the customer decide what is best for his/her system.

Bert

29

Bert Verhees schreef:

Ian McNicoll schreef:

Hi Bert,

Just for clarification, the work I have been doing in adding
demographics archetype support to the Ocean Editor is a personal
project, intended for the openEHR community and not an Ocean funded or

Thanks Ian, for your reply.

I didn’t know that the ArchetyoeEditor supports demograpic archetypes.

I didn’t know that the ArchetypeEditor is going to support demograpic archetypes.

(read your message to quick, excuse me)
Bert

30

Thanks for this Bert – a very helpful summary of the situation.

Cheers, Sam

31

Last Friday I built an XSD schema following the openEHR demographics
model available on the openEHR web. I have been able to import it to
LinkEHR and do some test with the available demographic archetypes
(thanks Sergio) and seems to work well. I've uploaded it to the
LinkEHR webpage so anyone can try it.
Check the download section of http://www.linkehr.com
The XSD schema can be downloaded there too.

Diego

32

Hi Ian

Are you extending the existing ADL parser to deal with the Demographic classes - it would be very interested in seeing that.

thanks
OP

33

Are there any defining rules as to what data should exist within the EHR vs Demographic models ?.

regards
OP

34

Hi ,

The ADL parsers (both .NEt and Eiffel) do already parse Demographics
model archetypes. I am working (slowly) on adding Demographics model
support to the Ocean Archetype Editor.

One things are a little more advance I will create a branch in the
Archetype editor subversion repository.

Ian

Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian@mcmi.co.uk

Clinical Analyst Ocean Informatics ian.mcnicoll@oceaninformatics.com
BCS Primary Health Care Specialist Group www.phcsg.org

35

And the Java ADL parser supports demographic archetypes too. In fact,
the parsers don't care if the archetype is about EHR or Demographics.
As long as the archetype has the correct ADL synatx, they are happy =)

Cheers
Rong

36

General principles:
EHR:

  • clinical data

  • clinically relevant demographic details, e.g. sex, date of birth, occupation

  • but otherwise, identifying information, and even patient id(s) can be avoided completely in the openEHR EHR, or they can be put in; see Common IM for discussion - http://www.openehr.org/releases/1.0.2/architecture/rm/common_im.pdf

  • clinically relevant admin data, e.g. admission, discharge, transfer, birth, death, …
    Demographic:

  • demographic data of any complexity, including personal contact information, professional qualifications

  • relationships, typically for relating professionals together into teams, groups and to employing organisations

  • thomas beale

Oxford Partnership wrote:

(attachments)

OceanCsmall.png

37

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

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

Gerard

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

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

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

38

Hi Thomas,

Good summary which I would agree with in principle, but this only
properly applies where openEHR is being used to completely define the
information requirements. In practice, openEHR is really being used in
3 slightly different contexts...

1. Where applications are being developed with a pure openEHR
'back-end' covering both the EHR and Demographics models. In this
context, a clear separation of models with the spilt of content you
have defined above, is the correct design.

2. Where applications are being designed with an openEHR back-end to
cover the EHR content but integrated with an existing Patient Admin
system (PAS) or other pre-defined Demographics model e.g a national
standard, HL7-CDA. In this case, the pure separation you defined
above may not be acheivable e.g. the PAS or national model may include
some aspects thatshould be in EHR such as Sex or Occupation.
Alternatively, it may be that the existing model will not allow some
3rd parties such as carers or other contacts to be stored in the PAS,
so these will have to be modelled in the EHR.

3. Where openEHR is used purely to gather and define clinical
content, with no expectation that either the EHR or Demographics
models will utlimately be modelled as openEHR within consuming
applications. This can cause some difficulties since, for instance,
while an archetype for surgical procedure does not need to explicitly
model the surgeon and any assistants as this is already catered for
within by the Participants attribute, clinical reviewers of the
archetype or templates, do like to be able to see this represented,
often structured within the main definition of the archetype. This was
the main reason that for the NHS modelling, we created some CLUSTER
archetypes, representing concepts like Organisation, Address,Carer
etc.

So although I mostly agree with Thomas's definitions as they apply to
a pure openEHR system, there are other circumstances where the overall
context of openEHR use is the key determinant. The original design
decision to make a clear separation between the EHR and Demographics
models makes perfect sense in the context of a pure openEHR
implementation, but we may have to explore the possibility of being
able to show some aspects of the Demographics model within an
archetype tree, to cope with legacy PAS and design-only contexts of
openEHR use.

Ian

Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian@mcmi.co.uk

Clinical Analyst Ocean Informatics ian.mcnicoll@oceaninformatics.com
BCS Primary Health Care Specialist Group www.phcsg.org

39

Hi Gerard,

I think this is theoretically and philosophically correct. However,for
the moment, given the difficulties I have described above, on
achieving a clear separation between Demographic and EHR entities in
practice, that at present, this would only confuse things further. At
present it is helpful to be able to model Device explicitly and
visibly within archetypes. We use a CLUSTER archetype so that this is
reusable and extensible.

We do already have external catalogs for e.g. lab tests, procedures
and medications etc but the problem (as for the Demographics entities)
is that the internal requirements for the catalog are usually a
mismatch for the requirements in the clinical record. It would of
course be possible to use the maximal dataset approach to define, for
instance, an archetype for device which encompassed a variety of
different perspectives - use in the clinial record, manufacturer's
requirements, servicing records, scheduling etc but as ever, it is
question of resources.It is going to be hard enough to model the
clinical record requirements without taking on this extra work.

Ian

Dr Ian McNicoll
office / fax +44(0)141 560 4657
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian@mcmi.co.uk

Clinical Analyst Ocean Informatics ian.mcnicoll@oceaninformatics.com
BCS Primary Health Care Specialist Group www.phcsg.org

40

Gerard Freriks wrote: