The concept of contribution

Technical (archive)
1

In the current issue (3.11) of the EHR reference model, we have documented the concept "contribution" as being that collection of TRANSACTIONs corresponding to a single clinical session. That is to say, due to a patient contact, there could be the following new TRANSACTIONs:

- patient contact (this causes a new VERSIONED_TRANSACTION)
- update to family history transaction (new version in existing VERSIONED_TRANSACTION)
- update to current medications (new version in existing VERSIONED_TRANSACTION)
- update to plan (new version in existing VERSIONED_TRANSACTION)
- etc

So the contribution in this case would be four TRANSACTIONs, each in distinct VERSIONED_TRANSACTIONs, and each having identical details in the CLINICAL_CONTEXT object.

Now... contributions are the unit of change of the record. The question is, do we need to be able to easily find them after the fact, or is it not really important. If it is not important most of the time, then we can do nothing, sicne they will in fact be findable by looking for those TRANSACTIONs which have the right CLINICAL_CONTEXT objects. However, this will be slow, as it means going through all transactions in the entire record. If it is important to be able find contributions quickly (as I have theorised in the past, and Andrew Goodchild at the DSTC suggests), then we need to formalise the concept.

Andrew has also suggested that EHR extracts are really a kind of "contribution", since they are effectively a bag of TRANSACTIONs to be applied to en EHR. While the TRANSACTIONs in the EHR_EXTRACT are not due to the same clinical session (they could be anything, depending on what the requestor asked for), their addition to the receiving EHR will in fact be a contribution.

If we are to formalise this concept, we need to have use cases showing when/why contributions need to be handled as explicit entities.

If we can prove the need, the following architectural possibilities suggest themselves:
- use FOLDERs to act as contributions, i.e. every time a contribution goes in, make a new FOLDER that contains the references to those TRANSACTIONs
- define CONTRIBUTION as a new subtype of FOLDER and use it as above
- if we consider a contribution to be the equivalent of an outer transaction in a nested transaction, then we might create a new TRANSACTION for each controbution, whose contents are links to the other transactions in the contribution,
- we could always add links to the first TRANSACTION in a contribution pointing to the other TRANSACTIONs in the group.

thoughts?

- thomas beale

2

[Forwarded response from Sam Heard]

Thomas Beale wrote:

In the current issue (3.11) of the EHR reference model, we have documented the concept "contribution" as being that collection of TRANSACTIONs corresponding to a single clinical session. That is to say, due to a patient contact, there could be the following new TRANSACTIONs:

- patient contact (this causes a new VERSIONED_TRANSACTION)
- update to family history transaction (new version in existing VERSIONED_TRANSACTION)
- update to current medications (new version in existing VERSIONED_TRANSACTION)
- update to plan (new version in existing VERSIONED_TRANSACTION)
- etc

So the contribution in this case would be four TRANSACTIONs, each in distinct VERSIONED_TRANSACTIONs, and each having identical details in the CLINICAL_CONTEXT object.

Now... contributions are the unit of change of the record. The question is, do we need to be able to easily find them after the fact, or is it not really important. If it is not important most of the time, then we can do nothing, sicne they will in fact be findable by looking for those TRANSACTIONs which have the right CLINICAL_CONTEXT objects. However, this will be slow, as it means going through all transactions in the entire record. If it is important to be able find contributions quickly (as I have theorised in the past, and Andrew Goodchild at the DSTC suggests), then we need to formalise the concept

I do not think that we do but I am happy to hear what people have to say. I
think it is the same function as putting the date back - ie a historical
date. In fact there is no reason why these things should all be changed at
once - a computer might be left on for an hour and then the rest is
committed - what is that?

Andrew has also suggested that EHR extracts are really a kind of "contribution", since they are effectively a bag of TRANSACTIONs to be applied to en EHR. While the TRANSACTIONs in the EHR_EXTRACT are not due to the same clinical session (they could be anything, depending on what the requestor asked for), their addition to the receiving EHR will in fact be a contribution.

This is a merge_audit and I do not think that they have the same status in
any way.

If we are to formalise this concept, we need to have use cases showing when/why contributions need to be handled as explicit entities.

If we can prove the need, the following architectural possibilities suggest themselves:
- use FOLDERs to act as contributions, i.e. every time a contribution goes in, make a new FOLDER that contains the references to those TRANSACTIONs
- define CONTRIBUTION as a new subtype of FOLDER and use it as above
- if we consider a contribution to be the equivalent of an outer transaction in a nested transaction, then we might create a new TRANSACTION for each controbution, whose contents are links to the other transactions in the contribution,
- we could always add links to the first TRANSACTION in a contribution pointing to the other TRANSACTIONs in the group.

thoughts?

NO way Jose - can I be any stronger than that?

- Sam

3

Dear Tom,

Greetings. I have been following your work for some time. It seems we have a
great opportunity now to get somewhere with all this, especially with the
convergence that you yourself identify in your 'Manifesto' document on the
GEHR site. I mean your concept of 'containers' and 'objects'.

I agree with it, but I was looking to the HL7 CDA to be the basic HES
Template, and then the objects (archetypes) fit in that. Bob Dolin from the
HL7 Structured Documents Group has described a way of doing this. Their
model might have a different emphasis from your 'versioned transaction'
concept. All 'Health Event Summaries' would have the same basic structure,
from simple free text documents to the Level 3 CDAs. These can then provide
a searchable data warehouse.

I have often thought that the distinction between 'persistence' and 'event'
transactions was unnecessary. I don't think we should be constructing an
ideal EHR at all. We should be working on a communication standard. I agree
that a HES or RDS system is not an EHR, but it should not try to be.
Instead, it might provide the currency to make EHRs out of. That's what
vendors are for. There can also be open source developers. If we just
capture the essentials, in containers of objects from all the health events,
that will give all the base data we need. The HES may start off primitive
(mainly free text), but will come to contain harvested data objects
(including prescription objects, family history objects etc.).

There will need to be some recognition of different levels of 'grain' in
data objects. I have often found your work confusing on this point. Blood
Pressure (or intraocular pressure) will make fine grained data objects.
Whole examinations (like 'diabetic foot exam') are a level of grain
coarser. There is an argument that templates of that level should not be
mandated or registered at all, being in the province of the clinician to
employ or change as required. The may in fact be mandated for certain
groups, but that is more for administrative control rather than medical
virtue.

If you put clinical objects in a standard format basket (the CDA), and put
the meta data in the header, you can use the header for retrieval and access
control. The standard could be as simple as that. There could be 'order
objects' which might give more context information about how data was
captured, but they would be optional.

This concept of the standard would not prevent you from continuing work on
your wonderful opensource EHR, and I wish you all success with it, but there
are other EHR models, and many as yet undreamed of. I think the
communication
'standard' could and should be simpler as outlined above

Regards

Mike Mair
NZHUG (NZ HL7 User Group)

[Forwarded response from Sam Heard]

Thomas Beale wrote:

>
> In the current issue (3.11) of the EHR reference model, we have
> documented the concept "contribution" as being that collection of
> TRANSACTIONs corresponding to a single clinical session. That is to
> say, due to a patient contact, there could be the following new
> TRANSACTIONs:
>
> - patient contact (this causes a new VERSIONED_TRANSACTION)
> - update to family history transaction (new version in existing
> VERSIONED_TRANSACTION)
> - update to current medications (new version in existing
> VERSIONED_TRANSACTION)
> - update to plan (new version in existing VERSIONED_TRANSACTION)
> - etc
>
> So the contribution in this case would be four TRANSACTIONs, each in
> distinct VERSIONED_TRANSACTIONs, and each having identical details in
> the CLINICAL_CONTEXT object.
>
> Now... contributions are the unit of change of the record. The
> question is, do we need to be able to easily find them after the fact,
> or is it not really important. If it is not important most of the
> time, then we can do nothing, sicne they will in fact be findable by
> looking for those TRANSACTIONs which have the right CLINICAL_CONTEXT
> objects. However, this will be slow, as it means going through all
> transactions in the entire record. If it is important to be able find
> contributions quickly (as I have theorised in the past, and Andrew
> Goodchild at the DSTC suggests), then we need to formalise the concept

I do not think that we do but I am happy to hear what people have to say.

I

4

Dear Sir,
The concept of "contribution" is definitely
'essential' for the functioninig of an efficient EHR
model.
For all practical purposes the memory of the patient
and the HCP is in term of "events".
Each of these "events" have a distinct title for
eg.Appendicectomy and have a number of examinations
inside them.
Each examination has a versioned_transaction as a
record.
Thus the event is a cluster of examinations and
contribution can act as a cluster of
versioned_transactions with a title.
During retrieval the Health care provider will have to
select a contribution after which only the related
Versioned_transactions will have to be retrieved.
Will this reduce the speed?
DR ANIKET JOSHI

5

I'll preface my comments by stating that after a very useful discussion with Andrew Goodchild today at the DSTC, I have agreed to write up a 2 or 3 page discussion paper on the subject of contributions with diagrams, whch I will put on the web. This will describe change management of the EHR seen from the configuration management paradigm, and describe what we think a "contribution" really is. I will publish this in the next couple of days, to help the discussion...

Mike Mair wrote:

I agree with it, but I was looking to the HL7 CDA to be the basic HES
Template, and then the objects (archetypes) fit in that. Bob Dolin from the
HL7 Structured Documents Group has described a way of doing this. Their
model might have a different emphasis from your 'versioned transaction'
concept. All 'Health Event Summaries' would have the same basic structure,
from simple free text documents to the Level 3 CDAs. These can then provide
a searchable data warehouse.

It will be searchable at some levels only. A CDA document is pretty close to what we are calling a contribution. The differences are:

- with an openEHR contribution, multiple transactions can be updated due to an interaction with the record,.e.g family history, plan etc. This is good from the point of view of having this information in thematically meaningful buckets. With CDA, all the content is in the document. If you want to build a picture of family history or current medications or care plan - especially if you want it nicely arranged under an agreed set of headings - it is going to be challenging...

- due to the level 1,2,3 conformance levels of CDA, any particular query searching for a particular kind of information, e.g, facts about family history will potentially work well for level 3 documents, but nothing can be said about the level 1 and level 2 documents in the repository, since in general there is no way for the level 3 query to work. Likewise, queries on level 2 attributes will only work for level 2 and 3 documents; only level 1 queries will correctly return results for all documents. This is not a criticism - it is exactly the expected behaviour of a repository of documents whose job is to provide different levels of structuring capability, due to the need to cope with input of varying quality.

Health event summaries appear (according to our work so far) to be a relatively easily archetypable family of structures. Some of their informatino will be what we call "persistent" information, i.e. what is found in the persistent transactions (what I called "thematic" transactions above).

I have often thought that the distinction between 'persistence' and 'event'
transactions was unnecessary. I don't think we should be constructing an
ideal EHR at all. We should be working on a communication standard. I agree

Interestingly, as we work with this concept, it becomes more and more obvious. Consider the EHR as a repository of documents or information entities, some of which are defined by purpose or theme, such as the typical transactions for "family history", "current meds", "lifestyle", "social history", "vacc history", "therapeutic precautions", "plan", "problem list", etc. These are what we call persistent transactions, and it is very clear that most EHR applications - both interactive and batch - will be hitting these transactions all the time.

In openEHR we are in the business of specifying the semantics of information in health records. It is true that some of the discussion goes beyond the remit of defining a communication standard. As long as this is clear, I don't think anyone has a problem with this. It is formally differentiated by the specification of EHR_EXTRACT versus EHR - the former is the basis for communication, while the latter is the basis for systems. But it is extremely useful to talk about what EHR systems need to be able to do, in order to figure out what the communication model should look like - I would go so far as to say that no-one is going to be able to design a good commuication standard without thinking about what is in the systems from which information comes (others disagree with this but that's the nature of debate!)

that a HES or RDS system is not an EHR, but it should not try to be.

I would agree

Instead, it might provide the currency to make EHRs out of. That's what
vendors are for. There can also be open source developers. If we just
capture the essentials, in containers of objects from all the health events,
that will give all the base data we need. The HES may start off primitive
(mainly free text), but will come to contain harvested data objects
(including prescription objects, family history objects etc.).

Interestingly, in discussions at HL7 Atlanta, the gulf between free text and structured information emerged - there appears to be a much greater free text data problem in the US than elsewhere, presumably due to the transcribing culture there. Designers of systems in the UK (Prodigy for example) would say that a good user interface simply obviates the problem of masses of free text. In our (admittedly limited) GPCG case studies here in Australia (OASIS, medical director data, sundry others) we haven't had a problem with struture - most of the data is structured. The structure isn't necessarily great, and the challenge has been to "discipline" it according to good archetypes. So no-one at this stage has suggested using the CDA for EHR as such. I'm not saying it could not be used - maybe when we get more into hospitals we will find it comes into use as a way of getting EHR subissions from legacy applications to an openEHR EHR server...

There will need to be some recognition of different levels of 'grain' in
data objects. I have often found your work confusing on this point. Blood
Pressure (or intraocular pressure) will make fine grained data objects.

agree - in openEHR, this is an ENTRY containing a LIST_S, containing 2 ELEMENTs, each with a value (if there is a protocol, it is another LIST_S, with the relevant ELEMENTs for "cuffsize" etc).

Whole examinations (like 'diabetic foot exam') are a level of grain coarser.

agree - in openEHR, the heading structure is an ORGANISER_TREE and ORGANISERs.

There is an argument that templates of that level should not be
mandated or registered at all, being in the province of the clinician to
employ or change as required. The may in fact be mandated for certain
groups, but that is more for administrative control rather than medical
virtue.

Well, whether or not they are mandated as such depends on the specific segment of the clinical community. This does not mean that they can't exist and shouldn't be used at all. All we are saying is how to produce them and use them. Whether they are mandatory is completely up to professional bodies and practitioners agreeing to agree on them. (And don't forget - archetypes are not fixed templates - you can easily design in the ability to have everything optional, extra trees of information etc).

If you put clinical objects in a standard format basket (the CDA), and put
the meta data in the header, you can use the header for retrieval and access
control. The standard could be as simple as that. There could be 'order
objects' which might give more context information about how data was
captured, but they would be optional.

The level 1 header data is nearly the same as the TRANSACTION revision history information in the REVISION_HISTORY object; we have been working on closing any remaining gaps, but they are very small now.

One thing I will say is that we have tried to base our work on an emerging theory of contexts (see the "Design Principles for the EHR" document) rather than ad hoc considerations. It isn't perfect, but is standing up pretty well to some hard questioning...

This concept of the standard would not prevent you from continuing work on
your wonderful opensource EHR, and I wish you all success with it, but there
are other EHR models, and many as yet undreamed of. I think the
communication 'standard' could and should be simpler as outlined above

I think we are much closer to it than you realise. Currently in openEHR, an EHR_EXTRACT, which is what you usually want to transmit consists of:

- the requested TRANSACTIONs
- demographic snapshots for all demographic entities mentioned in the transactions
- access control and other security/consent data
- terminology control data

EHR_EXTRACTs are the unit of request and reply between conformant EHR systems.

The most likely use of a CDA document is from a non-compliant system (which may have very little or a lot of structuring) _to_ an EHR system. The first thing an openEHR system would probably do with it is to pull it apart and apply its information as updates to the relevant transactions. There may be uses for output as well - the CDA group would have a better idea of the use cases here.

As for other EHR models, I don't know of too many that aren't particular system models, and I also don't know of many that are based on the notion of clear separation of information representation and knowledge concept models (i.e. reference model and archetypes). Models that I know of include:

- various models from U. Manchester including Alan Rector's PEN&PAD and others, COSMOS etc
- various models from Switzerland and Holland
- original GEHR
- CEN 13606 and predecessors
- ASTM data set
- various national health data sets, e.g. RFA4 (UK), GP dataset (Australia)
- GCPR model (US)
- the Corbamed (OMG HDTF) interface specifications
- CDA, which is not a model of the EHR as such, but is certainly related
- open source systems such as Gnumed, Freemed, OSCAR, OIO (which I admit we haven't spent enough time on)
- the VHA's Vista system (which we also have not reviewed as deeply as we should)

Other models which are no less interesting include the InterMountain Health system which we are looking at at the moment, but many of these are not available for review, as they are not standards and are closed.

I'm sure I've missed some important ones here, but one point to remember is: once you go the archetype route (or any similar 2-level approach), many previous models of EHRs are no longer that useful as direct inspiration for the openEHR reference model (they are however very useful for developing archetypes).

- thomas beale

6

aniket Joshi wrote:

Dear Sir,
The concept of "contribution" is definitely
'essential' for the functioninig of an efficient EHR model.
For all practical purposes the memory of the patient
and the HCP is in term of "events".
Each of these "events" have a distinct title for
eg.Appendicectomy and have a number of examinations inside them.
Each examination has a versioned_transaction as a record.
Thus the event is a cluster of examinations and
contribution can act as a cluster of
versioned_transactions with a title.

it seems to me this use of the word "event" is more what I would call an "episode", i.e. a period of time during which a number of related things happen (e.g. admission, examination, operation, review, discharge).

The defining aspect of "contribution" we are saying is that it is the unit of change to the EHR - it is due to a single "clinical session", which might be

- a patient contact
- a set of test results
- the acquisition and merging of an EHR extract or message

During retrieval the Health care provider will have to
select a contribution after which only the related
Versioned_transactions will have to be retrieved.
Will this reduce the speed?
DR ANIKET JOSHI

not completely clear on the querying scenario you are proposing here.

- thomas beale

7

Mike

Thanks for your letter. I just want to say something I think is important -
you cannot communicate unless you speak the same language. We have had HL7
for many years, we have had many other means of communicating information
and yet we are unable to communicate EHRs. This is, in my view, because the
information models underlying systems vary so much.

I have seen so many large projects to enable exchange of health information
over the years fail - I know believe that we need to share a basic
information model to allow this to take place.

The CDA is a good approach as it uses text as its data layer - and we can
all accept text. We can even display it with a transform - which is nice.
The problem is that there is a need to increase the complexity of the
information so far beyond text to get true interoperability of EHRs that the
text gets very complex and not human readable - though a transform is still
possible to display it.

So, in summary - we need to have a shared model of the EHR - implemented in
various ways and with greater or lesser transformation required for data and
semantic interoperability. And, text and schema is not enought - the EHR
needs to be expressed primarily within tools that will ensure that the XML
is conformant. I don't expect everyone to agree with this but there is
increasing empirical evidence.

Cheers, Sam

8

Hi,

A personal view.

HL7 (V2 and v3) and CEN messages can be considered fragments of an EHR.
Most often these fragments are used in the logistics of the patient or
healthcare provider. They integrate systems within an organisation.
CEN/TC251, HL7 CDA, GEHR and Structured Reporting (Dicom) are efforts to
record the information fragments in a document. A document with the prime
goal of registering a narrative based on the fragments. The narrative of the
Healthcare provider telling the medical story of the patient and his
problems. Secondly the narratives in a document must be transferable to
other documents.
All the relevant information fragments put together is the EHR.
GEHR, CEN, HL7 CDA and SR provide the syntaxes to tell the story. The
fragments (including the Terminologies) are the words. By adopting all the
same syntaxes medical stories become Interoperable provided that the
fragments are semantically interoperable.
I consider the Transactions as paragraphs. And the Contribution the set of
paragraphs that are committed (attested by signing off) to the record.
Each paragraph has an header and is collected in chapters with a title.
The headers and titles help the navigation and ordering of the information.

Work by CEN and GEHR show that this goal is completely feasible.
HL7 CDA developments are lacking behind because of a predominant focus on
CDA level 1 document messages.

With regards,

Gerard

Mike

Thanks for your letter. I just want to say something I think is important -
you cannot communicate unless you speak the same language. We have had HL7
for many years, we have had many other means of communicating information
and yet we are unable to communicate EHRs. This is, in my view, because the
information models underlying systems vary so much.

I have seen so many large projects to enable exchange of health information
over the years fail - I know believe that we need to share a basic
information model to allow this to take place.

The CDA is a good approach as it uses text as its data layer - and we can
all accept text. We can even display it with a transform - which is nice.
The problem is that there is a need to increase the complexity of the
information so far beyond text to get true interoperability of EHRs that the
text gets very complex and not human readable - though a transform is still
possible to display it.

So, in summary - we need to have a shared model of the EHR - implemented in
various ways and with greater or lesser transformation required for data and
semantic interoperability. And, text and schema is not enought - the EHR
needs to be expressed primarily within tools that will ensure that the XML
is conformant. I don't expect everyone to agree with this but there is
increasing empirical evidence.

Cheers, Sam

From: owner-openehr-technical@openehr.org
[mailto:owner-openehr-technical@openehr.org]On Behalf Of Mike Mair
Sent: Thursday, 6 June 2002 5:30 AM
To: Thomas Beale
Cc: openehr-technical@openehr.org
Subject: Re: The concept of contribution

Dear Tom,

Greetings. I have been following your work for some time. It
seems we have a
great opportunity now to get somewhere with all this, especially with the
convergence that you yourself identify in your 'Manifesto' document on the
GEHR site. I mean your concept of 'containers' and 'objects'.

I agree with it, but I was looking to the HL7 CDA to be the basic HES
Template, and then the objects (archetypes) fit in that. Bob
Dolin from the
HL7 Structured Documents Group has described a way of doing this. Their
model might have a different emphasis from your 'versioned transaction'
concept. All 'Health Event Summaries' would have the same basic structure,
from simple free text documents to the Level 3 CDAs. These can
then provide
a searchable data warehouse.

I have often thought that the distinction between 'persistence'
and 'event'
transactions was unnecessary. I don't think we should be constructing an
ideal EHR at all. We should be working on a communication
standard. I agree
that a HES or RDS system is not an EHR, but it should not try to be.
Instead, it might provide the currency to make EHRs out of. That's what
vendors are for. There can also be open source developers. If we just
capture the essentials, in containers of objects from all the
health events,
that will give all the base data we need. The HES may start off primitive
(mainly free text), but will come to contain harvested data objects
(including prescription objects, family history objects etc.).

There will need to be some recognition of different levels of 'grain' in
data objects. I have often found your work confusing on this point. Blood
Pressure (or intraocular pressure) will make fine grained data objects.
Whole examinations (like 'diabetic foot exam') are a level of grain
coarser. There is an argument that templates of that level should not be
mandated or registered at all, being in the province of the clinician to
employ or change as required. The may in fact be mandated for certain
groups, but that is more for administrative control rather than medical
virtue.

If you put clinical objects in a standard format basket (the CDA), and put
the meta data in the header, you can use the header for retrieval
and access
control. The standard could be as simple as that. There could be 'order
objects' which might give more context information about how data was
captured, but they would be optional.

This concept of the standard would not prevent you from continuing work on
your wonderful opensource EHR, and I wish you all success with
it, but there
are other EHR models, and many as yet undreamed of. I think the
communication
'standard' could and should be simpler as outlined above

Regards

Mike Mair
NZHUG (NZ HL7 User Group)

Sent: Wednesday, June 05, 2002 12:17 PM
Subject: Re: The concept of contribution

[Forwarded response from Sam Heard]

Thomas Beale wrote:

In the current issue (3.11) of the EHR reference model, we have
documented the concept "contribution" as being that collection of
TRANSACTIONs corresponding to a single clinical session. That is to
say, due to a patient contact, there could be the following new
TRANSACTIONs:

- patient contact (this causes a new VERSIONED_TRANSACTION)
- update to family history transaction (new version in existing
VERSIONED_TRANSACTION)
- update to current medications (new version in existing
VERSIONED_TRANSACTION)
- update to plan (new version in existing VERSIONED_TRANSACTION)
- etc

So the contribution in this case would be four TRANSACTIONs, each in
distinct VERSIONED_TRANSACTIONs, and each having identical details in
the CLINICAL_CONTEXT object.

Now... contributions are the unit of change of the record. The
question is, do we need to be able to easily find them after the fact,
or is it not really important. If it is not important most of the
time, then we can do nothing, sicne they will in fact be findable by
looking for those TRANSACTIONs which have the right CLINICAL_CONTEXT
objects. However, this will be slow, as it means going through all
transactions in the entire record. If it is important to be able find
contributions quickly (as I have theorised in the past, and Andrew
Goodchild at the DSTC suggests), then we need to formalise the concept

I do not think that we do but I am happy to hear what people

have to say.
I

think it is the same function as putting the date back - ie a historical
date. In fact there is no reason why these things should all be

changed at

once - a computer might be left on for an hour and then the rest is
committed - what is that?

Andrew has also suggested that EHR extracts are really a kind of
"contribution", since they are effectively a bag of TRANSACTIONs to be
applied to en EHR. While the TRANSACTIONs in the EHR_EXTRACT are not
due to the same clinical session (they could be anything, depending on
what the requestor asked for), their addition to the receiving EHR
will in fact be a contribution.

This is a merge_audit and I do not think that they have the

same status in

any way.

If we are to formalise this concept, we need to have use cases showing
when/why contributions need to be handled as explicit entities.

If we can prove the need, the following architectural possibilities
suggest themselves:
- use FOLDERs to act as contributions, i.e. every time a contribution
goes in, make a new FOLDER that contains the references to those
TRANSACTIONs
- define CONTRIBUTION as a new subtype of FOLDER and use it as above
- if we consider a contribution to be the equivalent of an outer
transaction in a nested transaction, then we might create a new
TRANSACTION for each controbution, whose contents are links to the
other transactions in the contribution,
- we could always add links to the first TRANSACTION in a contribution
pointing to the other TRANSACTIONs in the group.

thoughts?

NO way Jose - can I be any stronger than that?

- Sam

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

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

-
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

9

Gerard,

I feel that the idea of the EHR as being essentially a data base made up of
bits of messages is a fundamental misconception that is at the bottom of
many of our problems in health informatics. As first approximation it works
for GPs but sadly, it does not scale across the whole healthcare spectrum.

Any set structured information is designed for a primary purpose. This is
true of databases, documents, classifications and models. Any attempt to
use that information outside its original purpose is fraught with danger.
While it is true that a collection of documents can be thought of as an
electronic record, we have to take a lot of care when the information which
they contain is reused outside the original context of a message.

CEN and HL7 messages are just that - messages - from someone, to someone and
about someone at a moment in time. They have more in common with electronic
mail than with database structures. Any attempt to take information from a
message and put it into a database is potentially dangerous and needs to be
done with a real understanding of the data. This can only be done when
messages are rooted in very clearly defined use cases.

The scale of the problem is illustrated by thinking very clearly about ALL
of the potential users of medical records. In UK the Dept of Health
recognises more than 60 medical specialties. If you add in all of the other
clinical specialties then you have at least 100 distinct groups of people
who have their own specialised ways of working and requirements, including
audit and quality control issues, which ultimately determine how they need
their data to be structured. They cannot all use just one structure,
however much we would like this to be the case.

Kind regards

Tim

10

Gerard,

I feel that the idea of the EHR as being essentially a data base made up of
bits of messages is a fundamental misconception that is at the bottom of
many of our problems in health informatics. As first approximation it works
for GPs but sadly, it does not scale across the whole healthcare spectrum.

\

Tim, I agree with you.
Messages used in logistics are messages used for logistics.
The EHR is about narration.

Any set structured information is designed for a primary purpose. This is
true of databases, documents, classifications and models. Any attempt to
use that information outside its original purpose is fraught with danger.
While it is true that a collection of documents can be thought of as an
electronic record, we have to take a lot of care when the information which
they contain is reused outside the original context of a message.

CEN and HL7 messages are just that - messages - from someone, to someone and
about someone at a moment in time. They have more in common with electronic
mail than with database structures. Any attempt to take information from a
message and put it into a database is potentially dangerous and needs to be
done with a real understanding of the data. This can only be done when
messages are rooted in very clearly defined use cases.

I want to separate CEN from HL7. With CEN we focus on Documents with
narrative in a structured form either stored or transported between persons.
HL7 (v2 and v3) are about messages exchanged between databases for logistics
purposes. They contain no real narrative.

The scale of the problem is illustrated by thinking very clearly about ALL
of the potential users of medical records. In UK the Dept of Health
recognises more than 60 medical specialties. If you add in all of the other
clinical specialties then you have at least 100 distinct groups of people
who have their own specialised ways of working and requirements, including
audit and quality control issues, which ultimately determine how they need
their data to be structured. They cannot all use just one structure,
however much we would like this to be the case.
>>>

Next to the many types of users there are 10-20 different functions of any
EHR.

Kind regards

Tim

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

+31 252 544896
+31 654 792800

11

From: Gerard Freriks <gfrer@luna.nl>
Date: Fri, 07 Jun 2002 21:46:28 +0200

I want to separate CEN from HL7. With CEN we focus on Documents with
narrative in a structured form either stored or transported between persons.
HL7 (v2 and v3) are about messages exchanged between databases for logistics
purposes. They contain no real narrative.

This comment seems to point to a mis-conception about what HL7 is doing now
and what CEN has achieved over the past 10 years. Most existing HL7
implementations could be described as logistical, but the same is equally
true of CEN implementations. Indeed the work has proceded in parallel with
a good deal of duplication of effort.

It is quite wrong to characterize the present work of HL7 as being "for
logistics purposes" only. HL7 has about 30 different technical committees
and special interest groups, and while some do have a logistical focus, many
do not. The scope is so wide that few people have a full overview of all
the work that is going on.

I am not quite sure that I understand why you focus on the narrative
perspective as being so crucial. Ideas about story-telling and narratology
have been useful in understanding some of the ways in which GPs in
particular use (and misuse) medical records, but they only illustrate one of
the ways in which records are used (and these are mostly the ones where
computability is least important). The primary use of narrative to to
provide something that can be understood by a human being, while the value
of structure is to have something that is computable.

It is quite easy to produce a medical record which meets these requirements
for a SINGLE group of users (such as GPs), but it is a different thing
altogether to solve the problem for MULTIPLE groups. It is not the
narrative that creates the problem, but the structure. Most structures use
a version of a tree-like hierarchy, which can only support one perspective.
The way forward is to use structures which support MANY different
hierarchical structures at the same time.

The key word above is MANY. Existing systems support several ways of
looking at a medical record. Indeed the Abies GP system of 15 years ago
allowed the user to view the record according to different types of date, by
patient problem and by about 20 pre-defined characteristics (medication,
diagnoses etc) and by groups of coded entries (using the Read Code
hierarchy). Indeed the indexes for any medical record contained perhaps ten
time as many entries as the record itself. This worked rather well for GPs,
but did not migrate too well into secondary care, where there are multiple
and conflicting ways that different groups wanted to look at the data. The
solution to this problem is the evolution of virtual records for each group
of users, based on their own specific use cases. But this has little to do
with narrative...

Kind regards

Tim

12

Tim Benson wrote:

Gerard,

CEN and HL7 messages are just that - messages - from someone, to someone and
about someone at a moment in time. They have more in common with electronic

actually, you have to be careful - CEN messages are closer to this idea; HL7 messages are mostly from machine to machine.

mail than with database structures. Any attempt to take information from a
message and put it into a database is potentially dangerous and needs to be
done with a real understanding of the data. This can only be done when
messages are rooted in very clearly defined use cases.

Agree - this whole problem was one reason I wrote the "Health Information Standards Manifesto"

The scale of the problem is illustrated by thinking very clearly about ALL
of the potential users of medical records. In UK the Dept of Health
recognises more than 60 medical specialties. If you add in all of the other
clinical specialties then you have at least 100 distinct groups of people
who have their own specialised ways of working and requirements, including
audit and quality control issues, which ultimately determine how they need
their data to be structured. They cannot all use just one structure,
however much we would like this to be the case.

Well here I no longer agree. I agree if we are still using the "old way" of doing things - building a huge model of everything and turning it into software and databases. But as soon as you take the approach that the information is instances of lego bricks, the model is a model of lego bricks, and the particular configurations of lego bricks are defined by domain concept models - which are developed independently of the software and databases - this argument no longer holds water. I see no impediment whatever to to EHR systems which serves all types of users, as long as it is built on this architectural premise. And this premise is also the key to interoperabiity of data _between_ specialisations.

- thomas beale

13

Gerard Freriks wrote:

I want to separate CEN from HL7. With CEN we focus on Documents with
narrative in a structured form either stored or transported between persons.
HL7 (v2 and v3) are about messages exchanged between databases for logistics
purposes. They contain no real narrative.

This last statement is important - most HL7 messages are not likely to be the result or recording the dialogue of clinician/patient, or the clinician's own thinking; they are about recording intended/proposed/occurred events in the system, i.e. as Gerard says, logistical messages. These are two different functions, and if this is not understood properly, the industry is indeed going to have a hard time a) knowing how to use standards and b) knowing how to build systems.

- thomas beale

14

Thanks Sam,

You said:

you cannot communicate unless you speak the same language. We have had HL7

for many years, we have had many other means of communicating information
and yet we are unable to communicate EHRs. This is, in my view, because

the

information models underlying systems vary so much.

There are so many ontologies, and more being invented all the time. I agree
that you need to share some to communicate, but that can be negotiated. The
reality we have to deal with is polyontology, and there are tools being
developed to navigate between them. (eg the Ontology Inference Layer OIL and
DAML http://www.daml.org/ )

The CDA is a good approach as it uses text as its data layer - and we can
all accept text. We can even display it with a transform - which is nice.
The problem is that there is a need to increase the complexity of the
information so far beyond text to get true interoperability of EHRs

If we start by sharing the CDA as HES, we can migrate to more structured
data sharing as the level 2-3 CDA is developed. We are not trying for full
interoperability between EHRs at this stage - too hard! We can start simple
and grow into more complete interoperability with further iterations both of
the standard, and participant software.

- we need to have a shared model of the EHR - implemented in

various ways and with greater or lesser transformation required for data

and

semantic interoperability.

Why not just limit the 'standard' to dictionaries of archetypes (informed by
ontologies), and containers to convey them. 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.

< text and schema is not enough - the EHR

needs to be expressed primarily within tools that will ensure that the XML
is conformant. I don't expect everyone to agree with this but there is
increasing empirical evidence.

The question is, whose ontology, whose schemas, and that's just where we
are at. I think it is time to actually get the specs for clinical objects,
and start making some dictionaries, incorporating work already done, eg the
3M work, the GEHR archetypes, Dicom objects etc. However,it is possible
there will be many ontologies even for clinical material. I note that the
technique of Natural Language Processing is being applied to medical free
text especially in the US, delivering a dictionary of medical 'facts' ..
These would be a source of structured data and the CDA could be an exchange
format for documents that are secondarily 'structured' in this way. This
would generate more work for ontology integration tools!

We might get to a situation more like Natural Language, where 'meaning is
use', and terms come into existence, mutate, pass out of use, yet still
mange to 'mean' for their participant communities.

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.

Regards

Mike Mair (NZ HL7 User Group)

> From: http://www.daml.org/
> [mailto:owner-openehr-technical@openehr.org]On Behalf Of Mike Mair
> Sent: Thursday, 6 June 2002 5:30 AM
> To: Thomas Beale
> Cc: openehr-technical@openehr.org
> Subject: Re: The concept of contribution
>
>
> Dear Tom,
>
> Greetings. I have been following your work for some time. It
> seems we have a
> great opportunity now to get somewhere with all this, especially with

the

> convergence that you yourself identify in your 'Manifesto' document on

the

> GEHR site. I mean your concept of 'containers' and 'objects'.
>
> I agree with it, but I was looking to the HL7 CDA to be the basic HES
> Template, and then the objects (archetypes) fit in that. Bob
> Dolin from the
> HL7 Structured Documents Group has described a way of doing this. Their
> model might have a different emphasis from your 'versioned transaction'
> concept. All 'Health Event Summaries' would have the same basic

structure,

> from simple free text documents to the Level 3 CDAs. These can
> then provide
> a searchable data warehouse.
>
> I have often thought that the distinction between 'persistence'
> and 'event'
> transactions was unnecessary. I don't think we should be constructing an
> ideal EHR at all. We should be working on a communication
> standard. I agree
> that a HES or RDS system is not an EHR, but it should not try to be.
> Instead, it might provide the currency to make EHRs out of. That's

what

> vendors are for. There can also be open source developers. If we just
> capture the essentials, in containers of objects from all the
> health events,
> that will give all the base data we need. The HES may start off

primitive

> (mainly free text), but will come to contain harvested data objects
> (including prescription objects, family history objects etc.).
>
> There will need to be some recognition of different levels of 'grain' in
> data objects. I have often found your work confusing on this point.

Blood

> Pressure (or intraocular pressure) will make fine grained data objects.
> Whole examinations (like 'diabetic foot exam') are a level of grain
> coarser. There is an argument that templates of that level should not be
> mandated or registered at all, being in the province of the clinician to
> employ or change as required. The may in fact be mandated for certain
> groups, but that is more for administrative control rather than medical
> virtue.
>
> If you put clinical objects in a standard format basket (the CDA), and

put

> the meta data in the header, you can use the header for retrieval
> and access
> control. The standard could be as simple as that. There could be 'order
> objects' which might give more context information about how data was
> captured, but they would be optional.
>
> This concept of the standard would not prevent you from continuing work

on

> your wonderful opensource EHR, and I wish you all success with
> it, but there
> are other EHR models, and many as yet undreamed of. I think the
> communication
> 'standard' could and should be simpler as outlined above
>
> Regards
>
> Mike Mair
> NZHUG (NZ HL7 User Group)
>
> Sent: Wednesday, June 05, 2002 12:17 PM
> Subject: Re: The concept of contribution
>
>
> > [Forwarded response from Sam Heard]
> >
> > Thomas Beale wrote:
> >
> > >
> > > In the current issue (3.11) of the EHR reference model, we have
> > > documented the concept "contribution" as being that collection of
> > > TRANSACTIONs corresponding to a single clinical session. That is to
> > > say, due to a patient contact, there could be the following new
> > > TRANSACTIONs:
> > >
> > > - patient contact (this causes a new VERSIONED_TRANSACTION)
> > > - update to family history transaction (new version in existing
> > > VERSIONED_TRANSACTION)
> > > - update to current medications (new version in existing
> > > VERSIONED_TRANSACTION)
> > > - update to plan (new version in existing VERSIONED_TRANSACTION)
> > > - etc
> > >
> > > So the contribution in this case would be four TRANSACTIONs, each in
> > > distinct VERSIONED_TRANSACTIONs, and each having identical details

in

> > > the CLINICAL_CONTEXT object.
> > >
> > > Now... contributions are the unit of change of the record. The
> > > question is, do we need to be able to easily find them after the

fact,

> > > or is it not really important. If it is not important most of the
> > > time, then we can do nothing, sicne they will in fact be findable by
> > > looking for those TRANSACTIONs which have the right CLINICAL_CONTEXT
> > > objects. However, this will be slow, as it means going through all
> > > transactions in the entire record. If it is important to be able

find

> > > contributions quickly (as I have theorised in the past, and Andrew
> > > Goodchild at the DSTC suggests), then we need to formalise the

concept

> >
> >
> > I do not think that we do but I am happy to hear what people
> have to say.
> I
> > think it is the same function as putting the date back - ie a

historical

> > date. In fact there is no reason why these things should all be
> changed at
> > once - a computer might be left on for an hour and then the rest is
> > committed - what is that?
> >
> >
> > > Andrew has also suggested that EHR extracts are really a kind of
> > > "contribution", since they are effectively a bag of TRANSACTIONs to

be

> > > applied to en EHR. While the TRANSACTIONs in the EHR_EXTRACT are not
> > > due to the same clinical session (they could be anything, depending

on

> > > what the requestor asked for), their addition to the receiving EHR
> > > will in fact be a contribution.
> >
> >
> > This is a merge_audit and I do not think that they have the
> same status in
> > any way.
> >
> >
> > > If we are to formalise this concept, we need to have use cases

showing

> > > when/why contributions need to be handled as explicit entities.
> > >
> > > If we can prove the need, the following architectural possibilities
> > > suggest themselves:
> > > - use FOLDERs to act as contributions, i.e. every time a

contribution

> > > goes in, make a new FOLDER that contains the references to those
> > > TRANSACTIONs
> > > - define CONTRIBUTION as a new subtype of FOLDER and use it as above
> > > - if we consider a contribution to be the equivalent of an outer
> > > transaction in a nested transaction, then we might create a new
> > > TRANSACTION for each controbution, whose contents are links to the
> > > other transactions in the contribution,
> > > - we could always add links to the first TRANSACTION in a

contribution

15

From: "Mike Mair" <mikemair@es.co.nz>
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.

Mike - I agree with you here. Yes, interoperability depends on using a
common architecture for the information objects which are exchanged, but
this architecture can and should be both technology and domain independent.

Modern software development practice (e.g. UP) suggests that we distinguish
between specifications for requirements, design and implementation.
Requirements specifications are domain specific (use case and business
information models), Design specifications are ideally a realisation of the
requirements using a domain independent and technology independent
architecture; and Implementation is a technology specific realisation of the
design. A domain independent reference architecture (such as the HL7 RIM)
enables reuse across domains, while technology independence enables
implementation across channels and is more future-proof.

In my view, work on EHR standards should focus most attention on use case
and business information models, which is where the EHR-specific complexity
lies. The different use cases for EHRs can be realised using an
interoperability architecture (such as the RIM) and implemented using a
variety of technologies and channels (browsers, PDAs etc).

One of our most common mistakes is to start from the technology and work
backwards. This is especially hard to resist when you have already
committed to using a particular technology! However, standards must be
technology neutral.

Tim

16

Dear William,

I don't object to quoting me.
But I do object to your interpretation.

'Shortcomings of HL7'
It is NOT a 'shortcoming of HL7 and the RIM'.
HL7 messages a very successful in standardising messages that exchange
information between systems so these systems can be integrated. These
messages contain factual information: a lab test, an order, an admission.
All this is not a shortcoming of HL7. HL7 v2 is a success.
The RIM of HL7 v3 is a (partial) success. The concept is excellent.
Interoperability on a large scale needs a meta-model.

Talking about 'shortcomings'.
Helas the Rim is not stabile, yet. It will not become a formal part of the
normative standard. And then it is to much a mixture of IT specific parts
and Healthcare specific parts. The HL7 method has shortcomings because the
mapping of the R-MIM onto the RIM is done by hand. This will create
inconsistencies between different groups producing them. Finally HL7 creates
messages which content (dataset) is part of the standard to be used all over
the world. The standardised message will be to inflexible and to generic.

Because you didn't understand my comments I will try again.

I see communication (interoperability) take place on two levels.
1- Between machines in order to integrate them within an organisation. The
messages update databases. The messages don't contain narrative. They
contain factual data. (a lab-order, a lab result, etc) This type of
information exchange is essential.
2- Between persons or between the author and his record. This type of
registration (Document, EHR) takes place on the basis of the data that are
communicated in messages. But it is not about facts only, but about the
medical story of a patient as perceived by the narrator (healthcare
provider). The essence is that facts are interpreted as objective as
possible but always it will be the subjective interpretation of the author.
It contains the professional opinion based on the recorded facts. Because
the EHR must not be communicated but instantiated in a system, the Model on
which it is based will different from a model to be used for communication
only. This type of information exchange is essential, also.

With CEN/TC251 we co-operate with GEHR-Australia. As much as possible we
will align (harmonise) with HL7. We will have our own Reference Model. But
an Archetype Model as well. Together with the Archetype editor (containing
all the rules of the method) the collection of the Archetypes that user
communities will use form the HL7 R-MIM equivalent. But will be very
adaptable to local needs and stay consistent with the Reference Model and
rules.

Messages are primarily the turf of HL7 v2. I know that HL7 is working on
Structured Documents.
Documents are primarily the turf of CEN/TC251 - GEHR. CEN has messages as
well.

In short.
HL7 is for system integration within one organisation using messages. It is
about objective facts.
CEN is for people integration between separate organisations using the
document or record. It is about narrative.

The above is the most concise way to inform you of my opinion.
See you in Australia.

With regards

Gerard

Gerard,
    Do you mind if I quote some of your comments about the shortcomings
of HL7 and the RIM to the AMIA EHR group. We have established an EHR
initiavtive and I am trying to represent a broader existing status quo. I
then will assign a group to access the statements, and we will publish our
conclusions. I would be willing to share that published results.

I have had some difficulty in understanding the comments. The definition
of narrative and structured data seem to be different than mine. I am
particularly interested in what you propose as an alternative and what the
time line might be.

Thanks

Ed Hammond

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

+31 252 544896
+31 654 792800

17

Dear Tim,

I know that I painted things black and white.
But my picture contains some truth's, I think.

The scope of CEN and HL7 is not completely overlapping.
HL7 concentrated more or systems integration within an institutions.
And CEN more on exchange of information between organisations. The last
couple of years CEN moved towards Documents instead of messages. Plus CEN
started to standardise message components. Lego bricks.

My focus on narrative texts (the EHR) is obvious.
In medicine physicians exchange more than objective information and give
orders. They narrate the medical story of their patient, their thoughts and
deliberations about all the objective events that all constitute the EHR.
It is a personal account of a journey travelled together by the patient, its
relatives, and the healthcare provider.
In general it is NOT a narrative to be shared by many. The medical record is
a personal, subjective document. 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.
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.
Personally I don't believe in one all encompassing, fulfilling all needs for
all, Medical Record shared by all; now and in the future.

Gerard

From: Gerard Freriks <gfrer@luna.nl>
Date: Fri, 07 Jun 2002 21:46:28 +0200

I want to separate CEN from HL7. With CEN we focus on Documents with
narrative in a structured form either stored or transported between persons.
HL7 (v2 and v3) are about messages exchanged between databases for logistics
purposes. They contain no real narrative.

This comment seems to point to a mis-conception about what HL7 is doing now
and what CEN has achieved over the past 10 years. Most existing HL7
implementations could be described as logistical, but the same is equally
true of CEN implementations. Indeed the work has proceded in parallel with
a good deal of duplication of effort.

It is quite wrong to characterize the present work of HL7 as being "for
logistics purposes" only. HL7 has about 30 different technical committees
and special interest groups, and while some do have a logistical focus, many
do not. The scope is so wide that few people have a full overview of all
the work that is going on.

I am not quite sure that I understand why you focus on the narrative
perspective as being so crucial. Ideas about story-telling and narratology
have been useful in understanding some of the ways in which GPs in
particular use (and misuse) medical records, but they only illustrate one of
the ways in which records are used (and these are mostly the ones where
computability is least important). The primary use of narrative to to
provide something that can be understood by a human being, while the value
of structure is to have something that is computable.

It is quite easy to produce a medical record which meets these requirements
for a SINGLE group of users (such as GPs), but it is a different thing
altogether to solve the problem for MULTIPLE groups. It is not the
narrative that creates the problem, but the structure. Most structures use
a version of a tree-like hierarchy, which can only support one perspective.
The way forward is to use structures which support MANY different
hierarchical structures at the same time.

The key word above is MANY. Existing systems support several ways of
looking at a medical record. Indeed the Abies GP system of 15 years ago
allowed the user to view the record according to different types of date, by
patient problem and by about 20 pre-defined characteristics (medication,
diagnoses etc) and by groups of coded entries (using the Read Code
hierarchy). Indeed the indexes for any medical record contained perhaps ten
time as many entries as the record itself. This worked rather well for GPs,
but did not migrate too well into secondary care, where there are multiple
and conflicting ways that different groups wanted to look at the data. The
solution to this problem is the evolution of virtual records for each group
of users, based on their own specific use cases. But this has little to do
with narrative...

Kind regards

Tim

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

+31 252 544896
+31 654 792800

18

Mike,

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.
Artefacts based on the present HL7 version 3 RIM will prove to be
unimplementable as a system or object.

It is my opinion that a real co-operation between HL7 CDA and CEN/TC251 TF
EN 13606 is of importance. CEN and GEHR have a lot to offer to HL7.
But will this be recognised?

Gerard

Thanks Sam,

You said:

you cannot communicate unless you speak the same language. We have had HL7

for many years, we have had many other means of communicating information
and yet we are unable to communicate EHRs. This is, in my view, because

the

information models underlying systems vary so much.

There are so many ontologies, and more being invented all the time. I agree
that you need to share some to communicate, but that can be negotiated. The
reality we have to deal with is polyontology, and there are tools being
developed to navigate between them. (eg the Ontology Inference Layer OIL and
DAML http://www.daml.org/ )

The CDA is a good approach as it uses text as its data layer - and we can
all accept text. We can even display it with a transform - which is nice.
The problem is that there is a need to increase the complexity of the
information so far beyond text to get true interoperability of EHRs

If we start by sharing the CDA as HES, we can migrate to more structured
data sharing as the level 2-3 CDA is developed. We are not trying for full
interoperability between EHRs at this stage - too hard! We can start simple
and grow into more complete interoperability with further iterations both of
the standard, and participant software.

- we need to have a shared model of the EHR - implemented in

various ways and with greater or lesser transformation required for data

and

semantic interoperability.

Why not just limit the 'standard' to dictionaries of archetypes (informed by
ontologies), and containers to convey them. 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.

< text and schema is not enough - the EHR

needs to be expressed primarily within tools that will ensure that the XML
is conformant. I don't expect everyone to agree with this but there is
increasing empirical evidence.

The question is, whose ontology, whose schemas, and that's just where we
are at. I think it is time to actually get the specs for clinical objects,
and start making some dictionaries, incorporating work already done, eg the
3M work, the GEHR archetypes, Dicom objects etc. However,it is possible
there will be many ontologies even for clinical material. I note that the
technique of Natural Language Processing is being applied to medical free
text especially in the US, delivering a dictionary of medical 'facts' ..
These would be a source of structured data and the CDA could be an exchange
format for documents that are secondarily 'structured' in this way. This
would generate more work for ontology integration tools!

We might get to a situation more like Natural Language, where 'meaning is
use', and terms come into existence, mutate, pass out of use, yet still
mange to 'mean' for their participant communities.

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.

Regards

Mike Mair (NZ HL7 User Group)

From: http://www.daml.org/
[mailto:owner-openehr-technical@openehr.org]On Behalf Of Mike Mair
Sent: Thursday, 6 June 2002 5:30 AM
To: Thomas Beale
Cc: openehr-technical@openehr.org
Subject: Re: The concept of contribution

Dear Tom,

Greetings. I have been following your work for some time. It
seems we have a
great opportunity now to get somewhere with all this, especially with

the

convergence that you yourself identify in your 'Manifesto' document on

the

GEHR site. I mean your concept of 'containers' and 'objects'.

I agree with it, but I was looking to the HL7 CDA to be the basic HES
Template, and then the objects (archetypes) fit in that. Bob
Dolin from the
HL7 Structured Documents Group has described a way of doing this. Their
model might have a different emphasis from your 'versioned transaction'
concept. All 'Health Event Summaries' would have the same basic

structure,

from simple free text documents to the Level 3 CDAs. These can
then provide
a searchable data warehouse.

I have often thought that the distinction between 'persistence'
and 'event'
transactions was unnecessary. I don't think we should be constructing an
ideal EHR at all. We should be working on a communication
standard. I agree
that a HES or RDS system is not an EHR, but it should not try to be.
Instead, it might provide the currency to make EHRs out of. That's

what

vendors are for. There can also be open source developers. If we just
capture the essentials, in containers of objects from all the
health events,
that will give all the base data we need. The HES may start off

primitive

(mainly free text), but will come to contain harvested data objects
(including prescription objects, family history objects etc.).

There will need to be some recognition of different levels of 'grain' in
data objects. I have often found your work confusing on this point.

Blood

Pressure (or intraocular pressure) will make fine grained data objects.
Whole examinations (like 'diabetic foot exam') are a level of grain
coarser. There is an argument that templates of that level should not be
mandated or registered at all, being in the province of the clinician to
employ or change as required. The may in fact be mandated for certain
groups, but that is more for administrative control rather than medical
virtue.

If you put clinical objects in a standard format basket (the CDA), and

put

the meta data in the header, you can use the header for retrieval
and access
control. The standard could be as simple as that. There could be 'order
objects' which might give more context information about how data was
captured, but they would be optional.

This concept of the standard would not prevent you from continuing work

on

your wonderful opensource EHR, and I wish you all success with
it, but there
are other EHR models, and many as yet undreamed of. I think the
communication
'standard' could and should be simpler as outlined above

Regards

Mike Mair
NZHUG (NZ HL7 User Group)

Sent: Wednesday, June 05, 2002 12:17 PM
Subject: Re: The concept of contribution

[Forwarded response from Sam Heard]

Thomas Beale wrote:

In the current issue (3.11) of the EHR reference model, we have
documented the concept "contribution" as being that collection of
TRANSACTIONs corresponding to a single clinical session. That is to
say, due to a patient contact, there could be the following new
TRANSACTIONs:

- patient contact (this causes a new VERSIONED_TRANSACTION)
- update to family history transaction (new version in existing
VERSIONED_TRANSACTION)
- update to current medications (new version in existing
VERSIONED_TRANSACTION)
- update to plan (new version in existing VERSIONED_TRANSACTION)
- etc

So the contribution in this case would be four TRANSACTIONs, each in
distinct VERSIONED_TRANSACTIONs, and each having identical details

in

the CLINICAL_CONTEXT object.

Now... contributions are the unit of change of the record. The
question is, do we need to be able to easily find them after the

fact,

or is it not really important. If it is not important most of the
time, then we can do nothing, sicne they will in fact be findable by
looking for those TRANSACTIONs which have the right CLINICAL_CONTEXT
objects. However, this will be slow, as it means going through all
transactions in the entire record. If it is important to be able

find

contributions quickly (as I have theorised in the past, and Andrew
Goodchild at the DSTC suggests), then we need to formalise the

concept

I do not think that we do but I am happy to hear what people

have to say.
I

think it is the same function as putting the date back - ie a

historical

date. In fact there is no reason why these things should all be

changed at

once - a computer might be left on for an hour and then the rest is
committed - what is that?

Andrew has also suggested that EHR extracts are really a kind of
"contribution", since they are effectively a bag of TRANSACTIONs to

be

applied to en EHR. While the TRANSACTIONs in the EHR_EXTRACT are not
due to the same clinical session (they could be anything, depending

on

what the requestor asked for), their addition to the receiving EHR
will in fact be a contribution.

This is a merge_audit and I do not think that they have the

same status in

any way.

If we are to formalise this concept, we need to have use cases

showing

when/why contributions need to be handled as explicit entities.

If we can prove the need, the following architectural possibilities
suggest themselves:
- use FOLDERs to act as contributions, i.e. every time a

contribution

goes in, make a new FOLDER that contains the references to those
TRANSACTIONs
- define CONTRIBUTION as a new subtype of FOLDER and use it as above
- if we consider a contribution to be the equivalent of an outer
transaction in a nested transaction, then we might create a new
TRANSACTION for each controbution, whose contents are links to the
other transactions in the contribution,
- we could always add links to the first TRANSACTION in a

contribution

pointing to the other TRANSACTIONs in the group.

thoughts?

NO way Jose - can I be any stronger than that?

- Sam

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

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

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

-
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

19

From: Gerard Freriks <gfrer@luna.nl>
Date: Sat, 08 Jun 2002 17:54:55 +0200

<snip>

CEN started to standardise message components. Lego bricks.

</snip>

The issue of standardised components raises very interesting issues. There
are three different types of reusable element that we need to consider:

1. Reusable Business Patterns. These are sub-function type requirements
specifications, including use case and business information model, written
in a way to encourage re-use in requirements specifications.

2. Reusable Design Components. These are reusable chunks of design
specification (using a common architecture) which can be reused. CEN GPICs
and HL7 V3 CMETs seem to both fall into this category (and need to be
brought together).

3. Reusable Technology Components. These are reusable chunks of
technology-specific implementable specification. A good example is provided
by XML complex types within a referenced name space, which have been
developed specifically for reuse.

There is a clear relationship between these three types of reusable element,
but there is not a strict one to one mapping across them. They are not all
different aspects of the same Lego brick. They each are used by different
people to do different things. There may be a relationship between them,
but that is not necessary to achieve the major benefits of reusability. When
someone offers me a Lego brick, I want to be quite clear whether it is a
reusable business pattern, a design component or a technology component.

The predicted market for software components failed to grow as forecast
during the 1990s simply because the software components were just offered as
technology components (have widget, just pay me and then use it for whatever
you like), and not anchored in a common design architecture that dealt with
semantics properly, nor on business patterns.

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.

Tim

20

Ed, I agree entirely with what you say. I keep being reminded of the
excellent ISO definition of Consensus:

Consensus is general agreement, characterized by the absence of sustained
opposition to substantial issues by any important part of the concerned
interests and by a process which involves seeking to take into account the
views of all parties concerned and to reconcile any conflicting arguments.

Tim