The concept of contribution

Technical (archive)
21

Ed,

The invitation by the HL7 board is received well.
We will try to make it to Baltimore.

Harmonisation between CEN and HL7 is and stays our long term goal.
CEN achieved a lot towards this goal in project teams 41 and 42 working on
GPICS harmonised with HL7 and a set of Lab related messages based on GPICS.

The next phase of interactions between CEN and HL7 will have to be
discussed.
Templates, Archetypes, GPICS, Archetype methods, Datatypes, the EHR will be
topics of interest for all of us. Plus the way in which we both can have a
process of harmonisation that is effective pragmatic and reciprocal, might
be an other important topic.

Gerard

Ps: I'm giving you my personal thoughts.

It is difficult for me to stay on the sidelines. HL7 recognizes the value
of CEN and GEHR to its work. HL7, for example, has invited the chair of
CEN and the convenors of the work groups to the next meeting. What I think
we need to declare is what is real and what is pretend in working together
- on both sides. I declare and I believe that HL7 is interested in both
groups. What that means is not that we (or I) will drop what I am doing
and accept something different. What it means that I am willing to dialog
and debate the issues. I firmly believe that all groups will be mush better
off if we discuss and deal with our differences rather than each go our
different ways. We need to find a way for all groups to move ahead
together and still do what we each have to do to stay alive and even grow.
My belief is that V3 will become stable much more quickly than Gerard
implies. I agree that CDA needs to move ahead with CDA level 3. I am also
curious as to what clinical templates will do to level 3. I certainly hope
we can get together on architypes, GPICS, clinical templates, and Huffs/3M
clinical data models.

What say?

Ed Hammond
By the way, these are my opiniuons. I'm not sure anyone else wants them.

Ed

-- <private> --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800

22

Gerard,
      I like your personal thoughts., I am very excited abouyt the
possibilities of archetypes, GPICS, archetypes and such.. Tom Marley
proposed a merger of concepts into what he calls CHICS. While politically
incorrect, I like the possibilities. Thanks for the remarks.

Ed

23

Mike Mair wrote:

Why not just limit the 'standard' to dictionaries of archetypes (informed by
ontologies), and containers to convey them.

what we're doing is not much more than that. The containers are transactions or CEN compositions; to move them elswhere, wrap them in an EHR_EXTRACT.

We can use the access control
and document navigaton features of the CDA to convey the clinical objects
harvested at the health event. The level 2-3 CDA is a hybrid, part document,
part container. A Health Event Summary, a Transaction, a EHR Extract, and
a CDA document have very similar properties, including 'Persistence,
Stewardship, Wholeness, and human readiablity' (from the CDA specs).
Standards work is about achieving a shared way of doing something, so if we
all just adopt this 'low hanging fruit' the 'standard' will be served.

There's work enough to do to get a shared design for the clinical objects.
Thomas Beale suggests that the CDA might have a role integrating legacy
systems into his EHR, which might be fine if the rest of us are 'legacy'. We
can use the CDA for our baseline interoperability between all systems
including GEHR systems.

I'll just expand on what I meant - I meant "legacy" systems which represent their data primarily as narrative - unstructured text, not as structured data. This is where the CDA comes in because level 1 or level 2 will handle the various levels of structuring.

I am still not convinced that it is an EHR structure that has to be shared
for meaningful communication. Both aspects of interoperabiliy, functional
and semantic, can be served without sharing an EHR structure.

Ah but they cannot - if you can't write software which can assume the structures of data, you cannot do anything at all.

- thomas beale

24

Dear Gerhard,

You said:

Why the focus on HL7 only? CEN/TC251 has started work on the EN 13606 and

is precisely what you want. HL7 version 3 and >CDA will be to unstable for
some time to come. HL7 doesn't adopt the GEHR (CEN) two model approach.

Artifacts based on the present HL7 version 3 RIM will prove to be

unimplementable as a system or object.

We can be very encouraged that you may get together with HL7 on this.
However you (or was it Gunnar Klein) did say in your ?Berlin CEN meeting
2002 presentation (the presentation has disappeared from the
www.openehr.org. site) that EN 13606 had limited uptake because it was:

a) incomplete or have offered only partial coverage of the healthcare
domain;
b) unnecessarily complex;
c) too generic, leaving the various implementations too much variability in
how the models are applied to a given domain;
d) flawed, with some classes and attributes not implementable as published;
e) requiring expensive re-engineering of systems;
f) containing features not required by the
purchasers of clinical systems.

The time is evidently ripe for a synthesis. I agree about the importance of
narrative:
You said:

It is a narrative for personal usage.
When information is to be shared the author will select and rewrite parts
of his notes in order to meet a specific request by an other healthcare

provider.

This is the way people work. This is the way healthcare providers know how
to work with using paper systems.

Perhaps the record is a resource to make stories out of? The original
'syntagm' is just the first, and even that was an interpretation.The 'true'
story is unknowable.

I can see that objective information (orders, test results) can be shared

by

all without real problems. But people (good healthcare) will need

subjective

narrative as recorded in their personal Medical Records.

Free text remains indispensable, structured data is just the debris left
behind - it's a point of view...

Regards

Mike Mair

25

Mike,

I don't remember what was in the Berlin presentation by Gunnar, I think.

It is a fair list of reasons why the uptake is slow.
But what can one expect within a few years?
It took more than 6 years before a CEN standard on ECG-signals was used all
over the world.
What is used of HL7 version 2.2 or 2.3, I expect.

And both CEN and HL7 have a lot of optionalities, since the approach is
generic.

The re-engineering of systems is the case with standards used in
implementations in systems. And the EHR standard could be implemented in
systems it is not only a messaging standard.
Since Berlin we learned of several European implementations of the EHR
standard in systems and messages.
The implemented standard was a pre norm (ENV 13606) that after 3 years of
use is now up for revision. This revision will take on board the GEHR
Australia en USL work via the OpenEhr proposed Models.

Talking about narrative in Medicine.
The narrative is always subjective. It is what the narrator wants to write.
Most often it is the healthcare provider. What he writes is not THE TRUE
STORY it is the story as told by ....
Facts are recorded, interpreted, used or ignored and placed in certain
contexts. The highly subjective recorded result is what I call the Patiënt
Record. Fact and fiction. The EHR is the electronic version of this story
based on selected re-arranged facts. The free text plus facts is
the real stuff what medicine is about. And the more that is stored in a
structured way the better the EHR is computer processable.
Free text expressing the thoughts, the doubts, the professional expertise,
are not debris at all.

Medicine is more than recorded facts and pseudo facts.
Facts? Artefacts is a better phrase.

Gerard

Dear Gerhard,

You said:

Why the focus on HL7 only? CEN/TC251 has started work on the EN 13606 and

is precisely what you want. HL7 version 3 and >CDA will be to unstable for
some time to come. HL7 doesn't adopt the GEHR (CEN) two model approach.

Artifacts based on the present HL7 version 3 RIM will prove to be

unimplementable as a system or object.

We can be very encouraged that you may get together with HL7 on this.
However you (or was it Gunnar Klein) did say in your ?Berlin CEN meeting
2002 presentation (the presentation has disappeared from the
www.openehr.org. site) that EN 13606 had limited uptake because it was:

a) incomplete or have offered only partial coverage of the healthcare
domain;
b) unnecessarily complex;
c) too generic, leaving the various implementations too much variability in
how the models are applied to a given domain;
d) flawed, with some classes and attributes not implementable as published;
e) requiring expensive re-engineering of systems;
f) containing features not required by the
purchasers of clinical systems.

The time is evidently ripe for a synthesis. I agree about the importance of
narrative:
You said:

It is a narrative for personal usage.
When information is to be shared the author will select and rewrite parts
of his notes in order to meet a specific request by an other healthcare

provider.

This is the way people work. This is the way healthcare providers know how
to work with using paper systems.

Perhaps the record is a resource to make stories out of? The original
'syntagm' is just the first, and even that was an interpretation.The 'true'
story is unknowable.

I can see that objective information (orders, test results) can be shared

by

all without real problems. But people (good healthcare) will need

subjective

narrative as recorded in their personal Medical Records.

Free text remains indispensable, structured data is just the debris left
behind - it's a point of view...

Regards

Mike Mair

-- <private> --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800

26

Well, I wanted to refer to the clincal session,
perhaps Appendicectomy surgical record was a bad
example. I am not referring to the episode but the
clinical session.I have an architecture in which a
persons clinical sessions are displayed
chronologically with a title describing the clinical
session for example a Nuerological reference.
By giving a title to each session, the user can go the
specific session and go the depth of it.
The querying model which I am refering to is;
In my architecture,After the session is selected, the
related records need to be found out from the
transaction table and are displayed.This is efficient
because the related records are present in the
intermediate table.
In case of GEHR as the structure is OOPS,the query may
have to run through all the classes, which may take
significant time.
I think I have expressed myself.
DR ANIKET JOSHI

27

Tim Benson wrote:

If standards (including standards for reusable elements) are properly
anchored in specific use cases, then we can rid ourselves of a great deal of
the bloated optionality which is the curse of so many otherwise good
standards.

I agree, but they also need to be anchored in considerations from experience (analysis patterns if you like) and good design principles (which do not change the requirements, but may nevertheless change the way a standard is expressed).

- thomas beale

28

Dear Mike,

Whilst recovering from a heavy work schedule I'm trying to read through the openEHR mail discussion, and must apologise for not yet chipping in properly. However, as a quickie, I must take responsibility for those reasons why there has been poor uptake of ENV 13606. They were proposed as challenges for the new Task Force, if we wish to see the EN 13606 successor being taken up more positively by industry and by health services.

With best wishes,

Dipak

29

Dear All

There is no doubht that the solution will have a degree of complexity - just
look at HL7 v3 which is aimed at messaging. I believe that the HL7 and CEN
EHR approaches will align - and will include the level 3 CDA demands -
though it will take some time and must arise through implementation
experience. The time for smoked filled rooms and EHR standards is over for
us at openEHR and Ocean Infomatics. It is very helpful to have lots of
ideas, but unless people are working on an implementation it is almost
impossible to contribute in a major way.

I have put the challenge to CEN to have some pilot implementations of
Clinical Applications to GEHR (using our current trial implementations) and
see what the implications are of our current approach. At least 2 European
companies are interested.

I also believe that the EHR demands an information model designed
specifically for that purpose - the interoperability of EHRs. The fantacy
that sharing information based on different information models will be
straight forward is evolving - one only has to look at the difficulty of
sharing a word document amongst different software - it is often close. The
order of magnitude of complexity with health information is far greater.

So let us address the difficulties of information models, of clinical models
in a two level approach and work to create an EHR that is genuinely
interoperable. It will take resources - but to have it working as a sharable
component will take 0.1% of about 3 countries health IT development budget
and 10 good minds.

I think it is really starting to happen!

Cheers, Sam

30

Sam,

Well said.

We have for many years been operating under the ideas of 'interoperability'
and whilst tools such as HL-7 have been very successful in getting us
through these times the issue of EHR interoperability will be something else
yet again. Source system interoperability is one thing however (mostly
constrained within a controlled environment) but receiving systems such as
EHRs will have to be truly interoperable if they are to be effective.

The EHR is not a messaging system as some would have us believe (in some
incantations it could be seen to be just that) but it must be a system that
clinicians can rely on to be accurate and reflect 'real life'. If it has to
rely heavily on 'real time' messaging then the vagaries of our
telecommunications systems will have a significant impact on that level of
acceptance

(attachments)

InterScan_Disclaimer.txt (622 Bytes)

31

Hi

I am not a real techno but I understand and deeply interested in the
discussion. I had this vision of a real good electronic health record. It is
one own by the patient, carry by the patient, and presented to the health
care provider (whoever they are) by the patient (all over the world). The
Browser and XML or its improved version whatever it may be in the future is
the way to go.

This is the process
A patient visits a care provider and presents his e-card as a proof of
consent to treatment

The health care provider loads up the health record into the browser and
download the info into whatever system he is using (this applies to Hospital
as well), the health care provider can also choose to discuss the patient
with other health profession on line through the web.

When the patient leave the care provider, it is the responsibility of the
care provider to upload whatever he has done to the patient back to the
e-card and the patient goes away. Any subsequent test results etc, it is the
responsibility of the health care provider to contact the patient to have
the data put into the patient's e-card. (the patient can choose not to do so
- but it is of course to the patients benefit to do so)

The benefit of this is at any one time, the patient is the only person that
has a complete health history of himself and he owns it. (Solve the
ownership and privacy issue) After all, currently, the health care provider
will only know as much as what the patient choose to tell them anyway.

New industry will start up to take care of the situation and provide all
sorts of support to the e-card holders. These services include how to
download, how to backup or even help retrieve data in emergency etc. etc. -
god knows what will come up in the commercial world. Good or bad, no big
brothers.

When the patient dies, he can choose to sell his e-card for research
purposes and has money to bury himself - no burden to next of kin.

The reason I write these is that, I think I contribute as from a dumb user's
point of view, may be it has some bearing on the design and the structure of
the 'database' or 'rules' or whatever you may call it. The only
consideration will be where to put different types of health data in the
structure. It is upto the provider system to come up with the download and
upload method.

Cheers
Henry Li

32

Sam,

I agree that a certain degree of convegence is desirable and inevitable and will evolve over time based on implementation experience, but what is the reference to smoke filled rooms about?

Liora

33

Dear Thomas

>I am still not convinced that it is an EHR structure that has to be

shared

>for meaningful communication. Both aspects of interoperabiliy, functional
>and semantic, can be served without sharing an EHR structure.
>
Ah but they cannot - if you can't write software which can assume the
structures of data, you cannot do anything at all.

Popper would be proud of you - that's falsfiable. The structures of data and
those of EHR need not be the same (there's the rub)

Regards

Mike Mair

34

Mike Mair wrote:

Dear Thomas

I am still not convinced that it is an EHR structure that has to be

shared

for meaningful communication. Both aspects of interoperabiliy, functional
and semantic, can be served without sharing an EHR structure.

Ah but they cannot - if you can't write software which can assume the
structures of data, you cannot do anything at all.

Popper would be proud of you - that's falsfiable. The structures of data and
those of EHR need not be the same (there's the rub)

we are at cross-purposes with our terms - the whole raison d'etre of the openEHR EHR model is to state the semantics of shareable EHRs. How anyone implements their own EHR system is their business, and the standard says nothing about that. Clearly all software written to the shareable EHR standard has to understand what it is in order to be able to do anything..

- thomas

35

Henry

Thanks for the 'dumb' contribution. I hope that you can see that openEHR has
approached the problem in a way that will allow the sort of scenarion that
you have painted as well as a more complex scenario with a distributed
record - or even the big brother one record for each patient held centrally.
The reason is that we cannot predict the size of future work units or the
technology that will be around - only that the technology should not dictate
the work practices - only support them.

Cheers, Sam

36

Li, Henry wrote:

This is the process
A patient visits a care provider and presents his e-card as a proof of
consent to treatment

The health care provider loads up the health record into the browser and
download the info into whatever system he is using (this applies to Hospital
as well), the health care provider can also choose to discuss the patient
with other health profession on line through the web.

When the patient leave the care provider, it is the responsibility of the
care provider to upload whatever he has done to the patient back to the
e-card and the patient goes away. Any subsequent test results etc, it is the
responsibility of the health care provider to contact the patient to have
the data put into the patient's e-card. (the patient can choose not to do so
- but it is of course to the patients benefit to do so)

So now there are copies of the EHR a) on the patient's card, and b) on the system. Over time there will be many copies of the EHR, some more up to date than the copy on the patient's card. What's the point of having a copy of the EHR on the patient's card?

The benefit of this is at any one time, the patient is the only person that
has a complete health history of himself and he owns it. (Solve the

This won't be true - over time I doubt that anyone will have a complete history of the patient - they will all have partial histories, which admittedly is the curret situation, but I don't see any utility in having yet another copy of part of the EHR on the card.

Re: the fear of big brother - I agree this is real; but the solutions in my opinion lie in:

- distributed computing systems
- data management by clinical and/or public bodies (non profit enterprises in other words)
- strict governance of information and enforcement of consent
- data ownership by the patient

- thomas beale

37

Li, Henry wrote:

This is the process
A patient visits a care provider and presents his e-card as a proof of
consent to treatment

The health care provider loads up the health record into the browser and
download the info into whatever system he is using (this applies to Hospital
as well), the health care provider can also choose to discuss the patient
with other health profession on line through the web.

When the patient leave the care provider, it is the responsibility of the
care provider to upload whatever he has done to the patient back to the
e-card and the patient goes away. Any subsequent test results etc, it is the
responsibility of the health care provider to contact the patient to have
the data put into the patient's e-card. (the patient can choose not to do so
- but it is of course to the patients benefit to do so)

So now there are copies of the EHR a) on the patient's card, and b) on the system. Over time there will be many copies of the EHR, some more up to date than the copy on the patient's card. What's the point of having a copy of the EHR on the patient's card?

The benefit of this is at any one time, the patient is the only person that
has a complete health history of himself and he owns it. (Solve the

This won't be true - over time I doubt that anyone will have a complete history of the patient - they will all have partial histories, which admittedly is the curret situation, but I don't see any utility in having yet another copy of part of the EHR on the card.

Re: the fear of big brother - I agree this is real; but the solutions in my opinion lie in:

- distributed computing systems
- data management by clinical and/or public bodies (non profit enterprises in other words)
- strict governance of information and enforcement of consent
- data ownership by the patient

- thomas beale

One attractive option that goes some way to satisfy the above ideals is to have any particular data exist in only one primary location (backed up, of course), and therefore the total record "scattered" potentially around the world. The patient-held e-card (also backed up somewhere?) carries the _index_ to these locations/data, as well as being the physical part of a "key" that allows access to this data, and maybe also carrying some portion of the data (at least a summary of key events and critical information such as serious allergies, medication etc)

tony grivell

38

Hi,

After analysis done by the Smartcard people in the Netherlands they came to
the conclusion that Smartcards with significant medical information on it
need special safety procedures and back-up facilities.
These extra's necessitate a full back-up centrally and create
synchronisation problems. Everything is technically feasable.
But was to expensive.
They concluded: the smartcard must be used in the process of identification,
only. And even that was very expensive.

With regards,

Gerard

Li, Henry wrote:

This is the process
A patient visits a care provider and presents his e-card as a proof of
consent to treatment

The health care provider loads up the health record into the browser and
download the info into whatever system he is using (this applies to Hospital
as well), the health care provider can also choose to discuss the patient
with other health profession on line through the web.

When the patient leave the care provider, it is the responsibility of the
care provider to upload whatever he has done to the patient back to the
e-card and the patient goes away. Any subsequent test results etc, it is the
responsibility of the health care provider to contact the patient to have
the data put into the patient's e-card. (the patient can choose not to do so
- but it is of course to the patients benefit to do so)

So now there are copies of the EHR a) on the patient's card, and b)
on the system. Over time there will be many copies of the EHR, some
more up to date than the copy on the patient's card. What's the
point of having a copy of the EHR on the patient's card?

The benefit of this is at any one time, the patient is the only person that
has a complete health history of himself and he owns it. (Solve the

This won't be true - over time I doubt that anyone will have a
complete history of the patient - they will all have partial
histories, which admittedly is the curret situation, but I don't see
any utility in having yet another copy of part of the EHR on the
card.

Re: the fear of big brother - I agree this is real; but the
solutions in my opinion lie in:

- distributed computing systems
- data management by clinical and/or public bodies (non profit
enterprises in other words)
- strict governance of information and enforcement of consent
- data ownership by the patient

- thomas beale

One attractive option that goes some way to satisfy the above ideals
is to have any particular data exist in only one primary location
(backed up, of course), and therefore the total record "scattered"
potentially around the world. The patient-held e-card (also backed
up somewhere?) carries the _index_ to these locations/data, as well
as being the physical part of a "key" that allows access to this
data, and maybe also carrying some portion of the data (at least a
summary of key events and critical information such as serious
allergies, medication etc)

tony grivell

-
If you have any questions about using this list,
please send a message to d.lloyd@openehr.org

-- <private> --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800

39

Li, Henry wrote:

This is the process
A patient visits a care provider and presents his e-card as a proof of
consent to treatment

The health care provider loads up the health record into the browser and
download the info into whatever system he is using (this applies to Hospital
as well), the health care provider can also choose to discuss the patient
with other health profession on line through the web.

When the patient leave the care provider, it is the responsibility of the
care provider to upload whatever he has done to the patient back to the
e-card and the patient goes away. Any subsequent test results etc, it is the
responsibility of the health care provider to contact the patient to have
the data put into the patient's e-card. (the patient can choose not to do so
- but it is of course to the patients benefit to do so)

So now there are copies of the EHR a) on the patient's card, and b) on
the system. Over time there will be many copies of the EHR, some more up
to date than the copy on the patient's card. What's the point of having
a copy of the EHR on the patient's card?
>>>>>>

This is the position of the Dutch Smartcard Group.

The benefit of this is at any one time, the patient is the only person that
has a complete health history of himself and he owns it. (Solve the

This won't be true - over time I doubt that anyone will have a complete
history of the patient - they will all have partial histories, which
admittedly is the curret situation, but I don't see any utility in
having yet another copy of part of the EHR on the card.

Re: the fear of big brother - I agree this is real; but the solutions in
my opinion lie in:

- distributed computing systems
- data management by clinical and/or public bodies (non profit
enterprises in other words)
- strict governance of information and enforcement of consent
- data ownership by the patient

Agreed. But ...

"data ownership by the patiënt" will need some consideration.
I know that most laws in most countries are politically correct and give
rights to patients. But never ownership. Most often a right to inspect,
review, remove, and add information.
In my way of thinking, the author is the owner and one responsible. The
patiënt has the right to see his information and under certain conditions is
able to remove it or change it.
But what is "Information"?
I think that there are levels or types of information:

"Private Opinions" consisting of personal interpretations of raw data;
"Official Statements/opinions" consisting of professional interpretations of
raw data;
"Raw uninterpreted data" admitted to the EHR;
"Raw interpreted data" not admitted to the EHR, (yet)

Patiënt have rights towards the last two, but none with the first.
Healthcare providers must have the facility record private unripe thoughts
about the patiënt and its disease process.
The author os the information is acting as the proxy of the patiënt.
Patients should have no direct access to all the information. Only to
selected portions of the " Official opinions". The preferred way to inspect
and change is via the responsible proxy.

- thomas beale

-
If you have any questions about using this list,
please send a message to d.lloyd@openehr.org

-- <private> --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800

40

Tony Grivell wrote:

One attractive option that goes some way to satisfy the above ideals is to have any particular data exist in only one primary location (backed up, of course), and therefore the total record "scattered" potentially around the world. The patient-held e-card (also backed up somewhere?) carries the _index_ to these locations/data, as well as being the physical part of a "key" that allows access to this data, and maybe also carrying some portion of the data (at least a summary of key events and critical information such as serious allergies, medication etc)

whether it could even carry a reliable index of these locations is doubtful in my mind - people are too forgetful, they won't usually make the effort. But the critical information should of course be there. Most critical info is fairly non-volatile and does not need to be updated that often (current medications the probable exception).

- thomas