'Actionability' of orders

[thomas.beale]

Bernie Cohen wrote:

Surely the issue here is not merely that of the (binary?) nature of a
Speech Act, but the significance of that act to the enterprise within
which it occurs.
Thus even a delivery 'for information only' might invoke some action on
the part of the receiver, even if it is only the obligation to record its
arrival, e.g. for audit purposes.
What is missing here are definitions of the protocols governing the
performance of these acts by the enterprise's actors. This 'deontic
ontology' would permit the parties suitably to label each transaction and
to relate those labels to the appropriate protocols, which would indicate
the appropriate actions and enable the identification of, and recovery
from, transmission and other errors.
Formal languages, such as LOTOS etc., for defining such protocols hav
ebeen around for years, particularly in the telecoms industry. I suggest
that you investigate the inclusion of a suitable metalanguage.
Bernie

I missed this post this morning, but it hits the nail right on the head. The problem to be solved is protocols. They can be defined in the form of:
- protocol definitions, as in the telecom industry, to which Bernie refers above
- in terms of service interfaces, which can be designed to implement intended protocols of communication
They can be implemented in terms of:
- in message definitions, where different parts of the message, and different message types explicitly implement a protocol definition.
- in generic distributed object technology, e.g. RPC, Corba etc, where the messages are defined and created by magical tools which read the input service interface definitions to determine what the packets must be
- in generic messaging technology.

Personally, I believe we should be using service models and generic distributed technology.

- thomas beale

[thomas.beale]

Gerard Freriks wrote:

Hi,

In my parlance:
Messages are to update databases and are facts. eg lab results
Documents are to update humans with professional opinions that are signed.

The EHR and its extract are documents.
Depending on the type of archetype that what is recorded is:
-anamnesis (history)
-observation
- plan
- order
Each of these four types form a family of archetypes and indicate context.

Medication information inside an anamnesis archetype means that this is reported by the patient or others (eg the pharmacist when he sends a copy)
Medication information inside an observation archetype means that this is observed by the healthcare provider
Medication information inside a plan archetype means that this is an intention by the healthcare provider
Medication information inside an order archetype means that this is a prescription on behalf of the patient for others (pharmacist) to dispense/provide

What we miss in this list is the context where the extract reports that something has been executed.

I forgot to mention that the Instruction proposal can be viewed at http://my.openehr.org/wsvn/specification/TRUNK/publishing/proposals/Instruction.pdf?op=file&rev=0&sc=0

This is a very draft version, and is also somewhat out of date. But you will get the idea. Comments welcome.

- thomas beale

[thomas.beale]

Williamtfgoossen@cs.com wrote:

In een bericht met de datum 7-9-2005 0:13:04 West-Europa (zomertijd), schrijft gfrer@luna.nl:

- execution of a procedure.

And next we need the machinery to indicate the cancellation of these.

Yes, this is exactly as the two attributes in HL7 v3 RIM Acts:

moodcode to indicate the plan versus execution (INT versus EVN)
statuscode to determine whether this Act is active versus cancelled or on hold or similar.

actually, I think what is really needed is a state machine for the state of an Instruction. We have defined just such a state machine in the proposal (see http://my.openehr.org/wsvn/specification/TRUNK/publishing/proposals/Instruction.pdf?op=file&rev=0&sc=0). Any Instruction can be moved into one of the states by appropriate acts or conditions becoming true, which can be defined in the archetype. The moodcode of HL7 differentiates between Instruction and Instruction_act (ie. the execution of some part of an Instruction); the statuscode differentiates among teh various states possible for the Instruction when it is executed. What is missing in the HL7 approach is a way to define Instructions, including the mapping of real-world events and conditions to state-machine changes, in something like an archetype - in a clinically comprehensible way. What is most problematic is that some parts of such semantics _are_ being defined in RMIMs; the problem with this is a) that these kinds of definition originate in EHRs, not in the messages that carry the data from place to place, and b) such definitions need to be cleanly separeted from the machinery of messaging, and all the associated attributes. How HL7v3 will carry such information created in EHRs and based on archetypes will be very interesting to see indeed.

- thomas beale

[thomas.beale]

Hi William,

we would have preferred to be able to do this. But as we (and many others) have studied the problem over the years, the HL7 RIM looks less and less likely as a design basis for EHR information, including Instructions. Some of the problems (relating to just this topic) include:

• the lack of clarity over whether the RIM is an ontology of information or an ontology of reality (in other words: is Observation a model of some information documenting observations, or a model of an Observation process/act itself?). The HL7 documentation contains numerous conflicting statements about this. One practical consequence is that modellers of RMIMs etc are unclear about what attributes are needed to ensure that some object is a clear documentation of something (in which case it is not an Act, it is a documentation of an Act) or somehow a model of that thing actually occurring in time.
• the RIM doesn’t clearly take account of workflow thinking, which we believe to be the sensible basis for modelling a) specifications of future acts and b) their execution. In particular, the modellig of future acts needs to include the primitives: activities, timing, triggers, plus the ability to archetype all this so as to connect a generic workflow representation to specific clinical workflows.
• I agree that the dynamics of request/reply etc should be the same for most things, or at least a generic protocol definition should be able to encompass these ideas. The problem with the RIM is that it mixes such protocol notions with content notions. And to make things more difficult, there are many attributes in Act and Act-relationship which don’t make sense in those classes, only in instances of particular subclasses - these attributes are simply there so they can be removed during RMIM development. This makes it hard to use the model in normal object-oriented development.

Quite a number of experts are studying the ontological and other technical aspects of the RIM; I expect that we will be able to benefit from their research in the nrea future.

• thomas beale

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

[williamtfgoossen]

In een bericht met de datum 12-9-2005 3:41:30 West-Europa (zomertijd), schrijft Thomas.Beale@OceanInformatics.biz:

Hi William,

we would have preferred to be able to do this. But as we (and many others) have studied the problem over the years, the HL7 RIM looks less and less likely as a design basis for EHR information, including Instructions. Some of the problems (relating to just this topic) include:

Hello Thomas,

I agree with your points below (your comments TB, mine WG), this is still an issue to be worked out. Part of the solution of this however is dealt with on the D-MIM level. Perhaps you have not looked at the care provision D-MIM recently. It does include more detail for the clinical stuff that goes in the documentation. Of course the D-MIM has both the ontologies below. However, at R-MIM specification it is possible to distinghuish between them. In particular the careplan section does describe the information about what to document. It are mostly classes in intent mood: so telling what eventually to do. The other example is the event message in wich the actual observations, including time, value etc. are expressed.

TB:
t

he lack of clarity over whether the RIM is an ontology of information or an ontology of reality (in other words: is Observation a model of some information documenting observations, or a model of an Observation process/act itself?). The HL7 documentation contains numerous conflicting statements about this.

WG: I have never gone through all of these detials at this stage, merely because I work through the modelling use case by use case and find solution per needs basis. Until now we have been able to include a lot of stuff that clinicians want.

TB:
One practical consequence is that modellers of RMIMs etc are unclear about what attributes are needed to ensure that some object is a clear documentation

of something (in which case it is not an Act, it is a documentation of an Act) or somehow a model of that thing actually occurring in time.

WG: Yes, you need to make this distinction in a late stage by pulling out the right mood code out and making the constraint explicit.

TB:
t

he RIM doesn’t clearly take account of workflow thinking, which we believe to be the sensible basis for modelling a) specifications of future acts and b) their execution. In particular, the modellig of future acts needs to include the primitives: activities, timing, triggers, plus the ability to archetype all this so as to connect a generic workflow representation to specific clinical workflows.

WG: Well, this is not completely through. Yes for the RIM, no for the HL7 standard. Basically we deal with two key features of clinical information: the what = the structures (data, documentation, values) and the dynamics. The RIM with the D-MIM and R-MIMs helps to model structure. The UML notations as sequence diagrams and activity diagrams help to model the dynamics. It is very much feasible to analyse these seperately, model each in appropriate tools and finally integrate at higher model level and system/message level.

TB:
I

agree that the dynamics of request/reply etc should be the same for most things, or at least a generic protocol definition should be able to encompass these ideas.

WG: Yes, indeed I agree.

TB: The problem with the RIM is that it mixes such protocol notions with content notions.

WG: Well yes the RIM does, but conceive the RIM as your big box with virtual lego bricks, and the D-MIM as the space shuttle you built from it (without missing the last 5 atomic bricks, due to virtual unendlessness). From this analogy, the D-MIM can serve this purpose because both the protocol or guideline can be made explicit and linked to one single act / observation, or to a complex set of this, compared to the content itself as unrolled in the different observation classes needed.

TB:
And to make things more difficult, there are many attributes in Act and

Act-relationship which don’t make sense in those classes, only in instances of particular subclasses - these attributes are simply there so they can be removed during RMIM development. This makes it hard to use the model in normal object-oriented development.

WG: Well, we do have experiences now with three vendors that built their record systems based on the Care Provision D-MIM (as mimicked with some adaptations), and hundreds of R-MIM / CMET / GPIC / archetype / template examples in a relational database. The Care Provision Model serves as the CEN 13606 RIM, but then in proper HL7 v3 modelling, allowing entries and groupings of clinical documentation. The R-MIM / CMET / GPIC / archetype / template examples just fit in the slots in the XML message (CDA level 3 somewhere halfway), and is the specification for system development (storage, business logics like calculations, conditional execution, user interface).
WG
I believe it has the strength of your excellent new design to distinghuish between the systems operations and the expression of the clinical content, and the strength of the HL7 standard to guarantee semantic interoperability between more parties than 1 to 1, which is in my opinion the key flaw of the CEN 13606 and OpenEHR approach: every party willing to exchange documents / information must seek agreements with the receiving parties again on which archetypes to use / develop, so an unendless standardisation effort for very small content items. The formula n x n-1^2 tells me that the OpenEHR way stops to be feasible after about 5-7 parties step in. due to the many to many to many to many to many to many to many relationships on the archetype collections to agree upon with party 1, party 2, party 3 party 4, party 5, party 6.

TB:

Quite a number of experts are studying the ontological and other technical aspects of the RIM; I expect that we will be able to benefit from their research in the nrea future.

WG: I look forward to this, however, I would like to see the results of the study based on the D-MIMs that are made for purpose, where the RIM is more the collection of stuff to built with. I mean, if compared to the OpenEHR, the D-MIM is the part in which clinical content is expressed and dealt with.

My approach and study work is:

1. make explicit the clinicians knowledge, information and processes, (so roughly the semantics)
2. model this appropriately using UML artefacts (where the RIM is a specification of UML class diagrams), and of course: archetypes / templates / GPICS / R-MIMs / CMETs to express the real details clinicians look for and want to control with respect to content, terminology, coding. (roughly the interoperability based on standards)
3. implement the clinical material in technology, where it does not matter in principle if the technology is messages only, is a (distributed) database only, or if it is multiple databases with multiple messaging from one to another. We see different technical architectures dealing appropriately with the same clinical content. (so roughly the systems being able to semantically interoperate)

Of course each kind of technical representation would require constraining, and the examples you give above explain very well why this is necessary. A message via R-MIM to XML schema etc. needs a different constraining compared to a record system with database, logics and user interface, each adding to the requirements. And yes the RIM is probably to rich for the latter, where only a few attributes are necessary. OK, then from the same D-MIM, you constrain messages via adding/working out some peculiar unrolling of attributes and content, and for EHR by completely removing the rubbish you don’t need. I still think than that from the clinicians point of view it currently is better to start with the richer model, allowing both technical workouts and constrain from the rich model to the ‘poorer’ stuff (poorer here as sufficient for the function). From R-MIM to OpenEHR archetype works well, and is about 1 % of initial investment time with the benefit of well expressed clinical materials (70% of work), message standard with unique coding (20% of work), tools to ‘XMLise’ it (9% of work), and tools to ‘archetypise’ it (1 % of work). (Estimates from about 90 archetypes expressed in R-MIM). You could say: go from the 70 to the 1 % and save 19,… but if you need to work backwards from archetype to R-MIM / message, you probably would need to put in much much more effort.

• thomas beale

William Goossen

[thomas.beale]

Williamtfgoossen@cs.com wrote:

In een bericht met de datum 12-9-2005 3:41:30 West-Europa (zomertijd), schrijft Thomas.Beale@OceanInformatics.biz:

Hi William,

we would have preferred to be able to do this. But as we (and many others) have studied the problem over the years, the HL7 RIM looks less and less likely as a design basis for EHR information, including Instructions. Some of the problems (relating to just this topic) include:

Hello Thomas,

I agree with your points below (your comments TB, mine WG), this is still an issue to be worked out. Part of the solution of this however is dealt with on the D-MIM level. Perhaps you have not looked at the care provision D-MIM recently. It does include more detail for the clinical stuff that goes in the documentation. Of course the D-MIM has both the ontologies below. However, at R-MIM specification it is possible to distinghuish between them. In particular the careplan section does describe the information about what to document. It are mostly classes in intent mood: so telling what eventually to do. The other example is the event message in wich the actual observations, including time, value etc. are expressed.

TB:
t

he lack of clarity over whether the RIM is an ontology of information or an ontology of reality (in other words: is Observation a model of some information documenting observations, or a model of an Observation process/act itself?). The HL7 documentation contains numerous conflicting statements about this.

WG: I have never gone through all of these detials at this stage, merely because I work through the modelling use case by use case and find solution per needs basis. Until now we have been able to include a lot of stuff that clinicians want.

Hi William,
my concern here is that while you can "have what you want" by deleting inconvenient attributes where you feel like it, cloning others, renaming and so on, you are always in the business of building a new schema while doing this. Every such exercise is a new schema. This is not a good basis for building generic tools - neither to handle the clinical models (which are effectively embedded in the RMIM level) nor the information. How can one one piece of software for 2 messages when the Observation class from the RIM has been mutated in two different ways in each message? It might still be called Observation, but it won't be the same class in each. Message definitions just are not the right place to be doing clinical modelling.

TB:
t

he RIM doesn't clearly take account of workflow thinking, which we believe to be the sensible basis for modelling a) specifications of future acts and b) their execution. In particular, the modellig of future acts needs to include the primitives: activities, timing, triggers, plus the ability to archetype all this so as to connect a generic workflow representation to specific clinical workflows.

WG: Well, this is not completely through. Yes for the RIM, no for the HL7 standard. Basically we deal with two key features of clinical information: the what = the structures (data, documentation, values) and the dynamics. The RIM with the D-MIM and R-MIMs helps to model structure. The UML notations as sequence diagrams and activity diagrams help to model the dynamics. It is very much feasible to analyse these seperately, model each in appropriate tools and finally integrate at higher model level and system/message level.

I will be very interested to see how this all gets re-integrated smoothly...

TB: The problem with the RIM is that it mixes such protocol notions with content notions.

WG: Well yes the RIM does, but conceive the RIM as your big box with virtual lego bricks, and the D-MIM as the space shuttle you built from it (without missing the last 5 atomic bricks, due to virtual unendlessness). From this analogy, the D-MIM can serve this purpose because both the protocol or guideline can be made explicit and linked to one single act / observation, or to a complex set of this, compared to the content itself as unrolled in the different observation classes needed.

I should have been clearer here - I meant 'protocol' in the IT communications sense (as in http, ftp etc) not in the medical sense.

TB: And to make things more difficult, there are many attributes in Act and

Act-relationship which don't make sense in those classes, only in instances of particular subclasses - these attributes are simply there so they can be removed during RMIM development. This makes it hard to use the model in normal object-oriented development.

WG: Well, we do have experiences now with three vendors that built their record systems based on the Care Provision D-MIM (as mimicked with some adaptations), and hundreds of R-MIM / CMET / GPIC / archetype / template examples in a relational database. The Care Provision Model serves as the CEN 13606 RIM, but then in proper HL7 v3 modelling, allowing entries and groupings of clinical documentation. The R-MIM / CMET / GPIC / archetype / template examples just fit in the slots in the XML message (CDA level 3 somewhere halfway), and is the specification for system development (storage, business logics like calculations, conditional execution, user interface).
WG
I believe it has the strength of your excellent new design to distinghuish between the systems operations and the expression of the clinical content, and the strength of the HL7 standard to guarantee semantic interoperability between more parties than 1 to 1, which is in my opinion the key flaw of the CEN 13606 and OpenEHR approach: every party willing to exchange documents / information must seek agreements with the receiving parties again on which archetypes to use / develop, so an unendless standardisation effort for very small content items. The formula n x n-1^2 tells me that the OpenEHR way stops to be feasible after about 5-7 parties step in. due to the many to many to many to many to many to many to many relationships on the archetype collections to agree upon with party 1, party 2, party 3 party 4, party 5, party 6.

This a strange way to see things. With the archetypes approach, there are agreements at local, regional and national (maybe international) levels. Once they are agreed (e.g. we have 60+ national ones in Australia) then there is no argument about 1:1 agreements. In fact, I have never even heard anyone previously suggest that archetypes were about 1:1 negotiations! Quite the opposite; they will be (already are in some places) quite centrally available. The main advantage is that they are clear clinical models, independent of the details of messaging or other ways of communicating health information.

This is no different from groups of parties, jurisdictions etc agreeing on RMIMs or messages. The problem with the latter is that they are agreeing on a new clinical model and a new schema every time. There is no end to the new schemas.

Consider for example that a lab result could be sent from lab->EHR system, copied from EHR system->EHR system; stored in an EHR system; displayed on the screen; printed; and so on. No matter how many such situations, the model of the result should only have to be defined once. At the moment we can do this with archetypes & templates: define it all once and use it for everything. Only one schema (the reference model). A messaging standard that would help would be one that allows this. But HL7 forces users to define the clinical content of messages as part of their information schemas. Not only that, but if you want to use some or all of the lab result model in question in a different RMIM, there is no guarantee that it will be the same as in the first one; nor that it can be a re-usable component in general (since there is only one level of reusability - CMETs). How can I use the same definition for a screen form? THere is a whole lot of message attributes I don't want, but which I am forced to have.

Now we have a world containing N HL7 variants of some kind of lab result (each also a new data schema), and an archetype of the same result, resting on a single base ontology containing logical concepts of Observation, Evaluation, History, data structures, data types and so on. We can use this model to define EHR content, EHR Extracts, messages, any printed or display form (with additional display information of course). It is a single-source semantic model. And all the while we only have to work with one information schema.

And all of this misses a major point in the first place: the source of all health information is systems, not messages. If it is systems, then the designers of the information are the clinical (administrative, allied etc) professionals using the systems.

TB:

Quite a number of experts are studying the ontological and other technical aspects of the RIM; I expect that we will be able to benefit from their research in the nrea future.

WG: I look forward to this, however, I would like to see the results of the study based on the D-MIMs that are made for purpose, where the RIM is more the collection of stuff to built with. I mean, if compared to the OpenEHR, the D-MIM is the part in which clinical content is expressed and dealt with.

I think what you are saying is almost that we should ignore the RIM, and just see the set of DMIMs as HL7s information reference model. But we cannot get away from the fact that each RMIM, drawn from a DMIM creates a new schema, and is full of messaging attributes all over the place, and so on. (If I want to create an HL7 lab observation for microbiology result, I have to definine mood code on every node, since every node is an Act...but common sense dictates that it is only one result; it is therefore in OBS mood...there are 2 or 3 other mandatory Act attributes to which this also applies.).

My approach and study work is: 1. make explicit the clinicians knowledge, information and processes, (so roughly the semantics)
2. model this appropriately using UML artefacts (where the RIM is a specification of UML class diagrams), and of course: archetypes / templates / GPICS / R-MIMs / CMETs to express the real details clinicians look for and want to control with respect to content, terminology, coding. (roughly the interoperability based on standards)

well, maybe you know more than I do; I don't know of any easy integration of archetypes & templates and GPICS, RMIMs, CMETs etc. We tried it once at an HL7 meeting a couple of years ago, and just got lost in the attributes...I personally cannot see any obvious mapping...

3. implement the clinical material in technology, where it does not matter in principle if the technology is messages only, is a (distributed) database only, or if it is multiple databases with multiple messaging from one to another. We see different technical architectures dealing appropriately with the same clinical content. (so roughly the systems being able to semantically interoperate)

But this will be difficult, because each RMIM is a data schema as well.

Of course each kind of technical representation would require constraining, and the examples you give above explain very well why this is necessary. A message via R-MIM to XML schema etc. needs a different constraining compared to a record system with database, logics and user interface, each adding to the requirements.

so what you are saying here is that there are more constraints related to the technological deployment context of each message?

And yes the RIM is probably to rich for the latter, where only a few attributes are necessary. OK, then from the same D-MIM, you constrain messages via adding/working out some peculiar unrolling of attributes and content, and for EHR by completely removing the rubbish you don't need.

but this can never work for building re-usable software that a) wants to process the same clinical concept in different places (e.g. in an EHR service, in a query server; in a message gateway; in a presentation manager) and b) wants to be able to process more than one kind of message. There is an N x M space of deployment context x messages of software modules to build...

I still think than that from the clinicians point of view it currently is better to start with the richer model, allowing both technical workouts and constrain from the rich model to the 'poorer' stuff (poorer here as sufficient for the function).

but what is the logic of building clinical models of something starting from a model which is full of attributes which don't relate to most instances (quite apart from the fact that this practice violates the basic OO premise of model extensibility...)?

From R-MIM to OpenEHR archetype works well, and is about 1 % of initial investment time with the benefit of well expressed clinical materials (70% of work),

I assume you are talking about a human rewriting process here. There is no automatic transform that I know of. So already you are talking about 1 message structure and 1 archetype, with no obvious strategy for automatic conversion by computers...

message standard with unique coding (20% of work), tools to 'XMLise' it (9% of work), and tools to 'archetypise' it (1 % of work). (Estimates from about 90 archetypes expressed in R-MIM). You could say: go from the 70 to the 1 % and save 19,... but if you need to work backwards from archetype to R-MIM / message, you probably would need to put in much much more effort.

yes, but there are serious questions of quality and fitness for purpose which I have raised above, not just how many hours of work are involved...

- thomas

[williamtfgoossen]

In een bericht met de datum 12-9-2005 9:47:26 West-Europa (zomertijd), schrijft Thomas.Beale@OceanInformatics.biz:

Tom Beale wrote:

my concern here is that while you can “have what you want” by deleting
inconvenient attributes where you feel like it, cloning others, renaming
and so on, you are always in the business of building a new schema while
doing this. Every such exercise is a new schema. This is not a good
basis for building generic tools - neither to handle the clinical models
(which are effectively embedded in the RMIM level) nor the information.

As answer to my point of using the Care Provision D-MIM to express clinical content.

Here you have a point that changing the class names everytime, which I admit I am doing currently in the R-MIM / CMET / archetype / templates development, will not hold in the long run.
For the time being it allows me to express / model what clinicians want.
I will work however with Kai Heitmann to improve this approach so that against the HL7 v3 XML schema, a more pure archetype expression can be developed by means of keeping the proper class names and finding a solution for it via coding and using the attributes.

I agree on the need of generic tools:

so give me the tools that allows me to express the clinical content that can be exchanged between system in an international standardized matter.
OpenEHR does not do this for me, HL7 v3 D-MIM does it for the time being.

I wont to be independent of the technology, OpenEHR is not independent of technology, it forces to go in the

[thomas.beale]

Williamtfgoossen@cs.com wrote:

I agree on the need of generic tools:

so give me the tools that allows me to express the clinical content that can be exchanged between system in an international standardized matter.
OpenEHR does not do this for me, HL7 v3 D-MIM does it for the time being.

I wont to be independent of the technology, OpenEHR is not independent of technology, it forces to go in the

Hi William,

I'm not sure what is lacking in principle. Obviously openEHR isn't 'finished', but then again, what is? Our archetype tools (and coming template tools) are being used internationally, are based on an open and completely generic (i.e. not tied in any way to health, let alone EHRs or health messages) formalism (ADL), have a fully defined object model (the AOM), which has an XML-schema expression (tool-generated, coming soon). I don't want to say this is the perfect solution, but I have to admit I cannot think of how to be any more independent of technology specifics.

The archetypes being built are based on core features of the openEHR reference model (mostly Entry and data types level). However, there is a new CEN standards work item called the Archetype Knowledge Framework which will standardise the "domain base concept model", which will be a sharable ontology on which to base archetypes. We did try very hard to get HL7 in the past to see the need for this, but they have never been too interested in cooperating with other organisations. In any case, there are no archetypes in HL7, so I don't suppose anyone sees the need for a base ontology on which to base them (unless one is to claim the RIM, but then why bother making DIMs and RMIMs?). Whether this will change in the future is hard to judge; there appears to be an internal conflict between HL7 templates and HL7 RMIMs; I don't know how this will be resolved.

Whether each HL7 RMIM is "internationally standarised" is open to debate. Within HL7 this is presumably so. Whether it represents what clinicians around the world think is a BP measurement, an Apgar result, a cardiology exam, a chemotherapy administration I don't know, but seems doubtful to me, since the modelling process and framework is just too problematic.

Could you indicate which HL7 RMIMs are internationally standardised models of their chosen clinical concepts and where they can be downloaded from? It would be very interesting for the openEHR community to review them.

- thomas

[system]

Thomas,

When we agree that the scope of OpenEHR is to document the professional opinions and the facts on which these are based then:

An instance of an Instruction documents roughly what might be in a prescription

But it is semantically NEVER the same. It is the documentation of the process that lead to a prescription. It is NOT a prescription.

Gerard

– –

Gerard Freriks, arts

Huigsloterdijk 378

2158 LR Buitenkaag

The Netherlands

T: +31 252 544896

M: +31 654 792800

[system]

Whay are the arguments for your preference for service models and generic distrinuted technology?

Gerard

– –

Gerard Freriks, arts

Huigsloterdijk 378

2158 LR Buitenkaag

The Netherlands

T: +31 252 544896

M: +31 654 792800

[Jan_Ravet]

To some extent, this line is getting silly.

As a humble country GP, my primary interest is in the data. Most of the clinical data I want externally are numeric rather than Boolean, although I also have use for data that might be more suited to my primitive idea of a neural network: The rash “conforms fairly strongly with my impression of” an urticarial rash…

The opinions offered by other practitioners come into that category, as are the opinions which I expressed at previous encounters with this patient or clinical problem. However, all of this is fundamentally different from rocket science. Rocket science gives me the impression of being close to absolute. Maybe variations in weather will affect solutions close to the Earth, but the long stretches between planets, or between stars should be much more predictable than balls on a billiard table.

In contrast, there are very few absolute parameters in the “science” of Medicine. While not nearly as chaotic as weather patterns that might be affected by the beat of a butterfly’s wings, I want to be free to make my own assessment of the data I receive from other practitioners. Each datum I receive in that manner should be subjected to a degree of critical review. Looking at scaling on that “degree of crticial review” I expect IT analysts to want to differentiate as many states as possible, but I do not believe that we will reach a quantal level of granularity. I am prepared to give a high degree of credibility to the serum rhubarb. That is not to say that I would not expect some variation in the values reported by different laboratories on samples taken from the same patient and the same time, but I do expect the variations to be within the limits of error of the several different techniques that might be used to perform the assay. However, I do expect to see some difference in the “normal range” ascribed by each laboratory, and I also expect a greater degree of variation ( for “abnormal” results) in the “comment” line reported by each lab, and even each of the reviewing specialists within a given lab.

That’s with the relatively “hard” data provided by the lab. With radiology, I accept that the “report” is likely to be less black and white than the films, and that the report from the radiologist will vary from day to day, even if the same films are under review. So I can go down the list of specialist opinions right down to… well, there’s no need to be rude about those specialities. However, in each case, I need to be able to overlay my judgment array which will include:
the reproducibility of the observation: a. generally b. in the hands of the reporter
the usefulness of the observation
the quality of this reporter for this type of observation
…
Yes, it would be lovely, eventually, to mimic this process using software. However, my impression over the last three decades is that attempts to do this have merit at an academic level, both as an excercise in their own right and as a means of helping to train the next generation of practitioners in ths process.

The other aspect of "opinion"s is that they are evanescent. The patient’s “admission diagnosis” may have a strong positive correlation with the “discharge diagnosis”, but if we could claim identity between the two lists, there would be no need for tests after admission, no need for changes in management and certainly no need to record “opinions”. On the contrary, the initial (working) diagnosis is likely to be of limited precision, and to be accompanied by a list of other options. The tests ordered at that stage are ordered in the hope of being able to either strengthen or weaken the relative rankings of the differential diagnosis. Similarly, the effect of various treatment options can help to effect changes in those rankings, as will the opinons, prejudices and expertise of the various practitioners invited to participate in the process. The point to be made at this stage is that the addition of just one more datum at this point may be enough to change content as well as ranking within the “patient status report”. If this occurs, then we may find that the opinion expressed by the most prestigious and competent practitioner can be totally reversed within the span of the few seconds it takes for that datum to be perceived. This bears some similarity to the Humean dichotomy between deeds and moral issues.

So, much as I appreciate and indeed give a fair amount of weight to the opinions offered to me by others, those opinions are no more than information that I need to weigh in my own deliberations. Having played extensively with coding systems, it seems fairly clear that the best way of giving that opinion is verbally, with the language of the phone call, letter or email giving clues as to the matters in question, the observations used in moving toward the conclusion(s) reached and the advice sought or offered. Yes, I’m happy to compose the bulk of my letter from elements formally represented in my medical record and to parse the reply for similar elements, but the opinions expressed are likely to have their value reduced if they are removed from that context and the implicit timeframe.

By all means let us look at ways of extracting useful elements from either letter, but let’s not lose sight of the value of the letter which is undoubtedly greater than the sum of its parts.

Jan Ravet

[thomas.beale]

Hi Gerard,

Gerard Freriks wrote:

Whay are the arguments for your preference for service models and generic distrinuted technology?

a) pragmatically: that is the way the world has been going for over 15 years (RPC, Corba, OSF/DCE, webservices, WSDL etc etc)
b) theoretically: the separation of computational (service model) and informational viewpoints (a la ISO RM/ODP) has major benefits in systems development and deployment: you can develop models of information separately from models of how the information will be commucated; and you can redeploy a back-end behind a service without users of the service needing to be changed.

- thomas

[thomas.beale]

Gerard Freriks wrote:

Thomas,

When we agree that the scope of OpenEHR is to document the professional opinions and the facts on which these are based then:

An instance of an Instruction documents roughly what might be in a prescription

But it is semantically NEVER the same. It is the documentation of the process that lead to a prescription. It is NOT a prescription.

clearly not. A prescription is a piece of paper in my hand from your doctor's rooms, containing an order for a medication from a pharmacy, and instructions to me (to be typed or printed at the pharmacy). But, if you wanted to generate such a physical (or electronic) document from an openEHR Instruction, all the information would be there (the only exception would be if you wanted to indicate a particular pharmacy to go to).

- thomas

[system]

I agree.

Gerard

– –

Gerard Freriks, arts

Huigsloterdijk 378

2158 LR Buitenkaag

The Netherlands

T: +31 252 544896

M: +31 654 792800

[system]

Thomas,

All the information in both the EHRsystem and the prescription on paper or electronicly is the same archetype/template.
Only the intention is different.
In the former it is about documentation.
The latter is the prescription order that was documented.

Can we agree that documentation is within the scope of OpenEHR (and EN136060) and that the electronic prescription as an order is not?
And that the electronic prescription as an order is THE scope of HL7v2 and HL7v3 messages.

In my view this subtle distinction in scope indicates where OpenEHR/CEN and HL7 are active and where they meet and are able to co-operate.

When we agree about the scopes. I suggest that we revisit the present scope statements of OpenEHR and EN13606 and make things more explicit.

Gerard

– –

Gerard Freriks, arts

Huigsloterdijk 378

2158 LR Buitenkaag

The Netherlands

T: +31 252 544896

M: +31 654 792800

[thomas.beale]

Gerard Freriks wrote:

Thomas,

All the information in both the EHRsystem and the prescription on paper or electronicly is the same archetype/template.
Only the intention is different.
In the former it is about documentation.
The latter is the prescription order that was documented.

Can we agree that documentation is within the scope of OpenEHR (and EN136060) and that the electronic prescription as an order is not?
And that the electronic prescription as an order is THE scope of HL7v2 and HL7v3 messages.

from the openEHR point of view, the content of a prescription is in the record. The 'order' corresponding to a prescription is simply a notification from the prescriber to the filler. This notification may be communicated in two ways:
a) by the patient turning up
b) by an electronic notification from EHR source to filler's system asking for the prescription in the EHR to be acted upon
c) by an electronic message carrying the content (due to shared EHR not being possible) of the prescription and the notification

What kind of electronic notification is used in b) and c) depends mostly on what receiver systems want to receive. At this stage it could be similar to a v2 message. The problem with the HL7 message though is that it is going to want to carry the content (translated into HL7-speak, and back out of it at the other end) i.e. it will always want to do c) above, so we have to be very careful about that. It is clearly preferable if we are forced to work in mode c) that an EN13606 message be used instead; then we are arguing for the addition of some notification information in the EHR Extract, which Gerard and Sam have already flagged earlier in this thread. I agree: that should definitely be explored. Then the obvious way to model b) is to define something that looks like the EN13606 Extract (augmented with notification info), but allowing no content, but rather a logical pointer to some content.

I have to admit, I had not thought my way completely through this line of reasoning before, but I think this is where Gerard and Sam are coming from. I would go so far as to say that appropriate change requests should be made to openEHR and to EN13606 to provide the support for this.

The key point to remember is that the EHR and other related systems are the sources or sinks of the information; messages should be able to carry whatever content they require, with 0 semantic translation, and minimal syntactic translation. This is not the case today with HL7 messages. I have just reviewed in detail some HL7v2 interfaces in Queensland Health in Australia, and it is clear that the messages are imposing semantic as well as syntactic translations. HL7v3 messages will do the same. It is also clear that this is an undesirable situation; it is like the postal service forcing everyone to write letters in latin - and only using the postal service's allowed lexicon of latin phrases, even though the sender and receiver both want to speak english. Anyone who has seen the Monty Python Hungarian phrase-book sketch will know what I mean.

This is why I say that service models (which are agnostic as to content) are a preferable approach. EN13606 is pretty agnostic as to content, and can easily fit into such a framework.

- thomas

[system]

– –

Gerard Freriks, arts

Huigsloterdijk 378

2158 LR Buitenkaag

The Netherlands

T: +31 252 544896

M: +31 654 792800

Gerard Freriks wrote:

Thomas,

All the information in both the EHRsystem and the prescription on paper or electronicly is the same archetype/template.
Only the intention is different.
In the former it is about documentation.
The latter is the prescription order that was documented.

Can we agree that documentation is within the scope of OpenEHR (and EN136060) and that the electronic prescription as an order is not?
And that the electronic prescription as an order is THE scope of HL7v2 and HL7v3 messages.

from the openEHR point of view, the content of a prescription is in the record.

Correct to a degree.
The record is there to document what has happened. eg a prescription was written. This has the status of an order TO BE fulfilled.
The notification (in any form) has the same content as what is in the record, but is NOT the same.
The notification must indicate (or contain) explicitly what is prescribed and has the status of an order to be fulfilled.

The ‘order’ corresponding to a prescription is simply a notification from the prescriber to the filler. This notification may be communicated in two ways:
a) by the patient turning up
b) by an electronic notification from EHR source to filler’s system asking for the prescription in the EHR to be acted upon
c) by an electronic message carrying the content (due to shared EHR not being possible) of the prescription and the notification

What kind of electronic notification is used in b) and c) depends mostly on what receiver systems want to receive. At this stage it could be similar to a v2 message. The problem with the HL7 message though is that it is going to want to carry the content (translated into HL7-speak, and back out of it at the other end) i.e. it will always want to do c) above, so we have to be very careful about that. It is clearly preferable if we are forced to work in mode c) that an EN13606 message be used instead; then we are arguing for the addition of some notification information in the EHR Extract, which Gerard and Sam have already flagged earlier in this thread. I agree: that should definitely be explored. Then the obvious way to model b) is to define something that looks like the EN13606 Extract (augmented with notification info), but allowing no content, but rather a logical pointer to some content.

I have to admit, I had not thought my way completely through this line of reasoning before, but I think this is where Gerard and Sam are coming from. I would go so far as to say that appropriate change requests should be made to openEHR and to EN13606 to provide the support for this.

We are getting somewhere.
In my mind, and on the basis of many years of a collective experience, we humans only trust a complete document handed to us, sent to us, that tells the whole story. This is what legal persons want to happen.
Not a thing with a pointer to a place with content where you have no jurisdiction.
Therefor I think that option C is what we are after when there is an order for an other in an other legal entity.
Within the legal entity options a and b will be ok.

The key point to remember is that the EHR and other related systems are the sources or sinks of the information;

Of events that have happened. They DOCUMENT.

messages should be able to carry whatever content they require, with 0 semantic translation, and minimal syntactic translation. This is not the case today with HL7 messages. I have just reviewed in detail some HL7v2 interfaces in Queensland Health in Australia, and it is clear that the messages are imposing semantic as well as syntactic translations. HL7v3 messages will do the same. It is also clear that this is an undesirable situation; it is like the postal service forcing everyone to write letters in latin - and only using the postal service’s allowed lexicon of latin phrases, even though the sender and receiver both want to speak english. Anyone who has seen the Monty Python Hungarian phrase-book sketch will know what I mean.

This is why I say that service models (which are agnostic as to content) are a preferable approach. EN13606 is pretty agnostic as to content, and can easily fit into such a framework.

You are correct about your metaphor.
But many people want to write and read in Latin.

In a services environment this will be up to the actors that will make use of the services.
They will speak Latin when they want to or OpenEHR (EN13606) when this fits their needs.

[system]

Dear John,

I agree. OpenEHR (and HL7) is about a part of the equation.
They need an infrastructure but this is outside of the scopes.
In some places they are touching it.

In CEN/tc251 we are working on a standard: Health Information Systems Architecture.
This will address the infrastructural topics.

With regards

[thomas.beale]

Gerard Freriks wrote:

from the openEHR point of view, the content of a prescription is in the record.

Correct to a degree.
The record is there to document what has happened. eg a prescription was written. This has the status of an order TO BE fulfilled.
The notification (in any form) has the same content as what is in the record, but is NOT the same.
The notification must indicate (or contain) explicitly what is prescribed and has the status of an order to be fulfilled.

when I talk of 'notification', I am not talking about content; I am talking about a notification from a provider to a pharmacy (in this example), referring to a piece of information in an EHR system which expresses the prescription, and indicating that the pharmacy should act upon it for the patient in question.

The 'order' corresponding to a prescription is simply a notification from the prescriber to the filler. This notification may be communicated in two ways:
a) by the patient turning up
b) by an electronic notification from EHR source to filler's system asking for the prescription in the EHR to be acted upon
c) by an electronic message carrying the content (due to shared EHR not being possible) of the prescription and the notification

What kind of electronic notification is used in b) and c) depends mostly on what receiver systems want to receive. At this stage it could be similar to a v2 message. The problem with the HL7 message though is that it is going to want to carry the content (translated into HL7-speak, and back out of it at the other end) i.e. it will always want to do c) above, so we have to be very careful about that. It is clearly preferable if we are forced to work in mode c) that an EN13606 message be used instead; then we are arguing for the addition of some notification information in the EHR Extract, which Gerard and Sam have already flagged earlier in this thread. I agree: that should definitely be explored. Then the obvious way to model b) is to define something that looks like the EN13606 Extract (augmented with notification info), but allowing no content, but rather a logical pointer to some content.

I have to admit, I had not thought my way completely through this line of reasoning before, but I think this is where Gerard and Sam are coming from. I would go so far as to say that appropriate change requests should be made to openEHR and to EN13606 to provide the support for this.

We are getting somewhere.
In my mind, and on the basis of many years of a collective experience, we humans only trust a complete document handed to us, sent to us, that tells the whole story. This is what legal persons want to happen.
Not a thing with a pointer to a place with content where you have no jurisdiction.

you would never see that; don't forget we are talking computational systems here - the user would of course see the content. My description applies to what goes on behind the scenes.

Therefor I think that option C is what we are after when there is an order for an other in an other legal entity.
Within the legal entity options a and b will be ok.

Well, option b) is more futuristic, and a) and c) both exist now. b) undoubtedly exists in some places right now but is not widespread.

The key point to remember is that the EHR and other related systems are the sources or sinks of the information;

Of events that have happened. They DOCUMENT.

not just events that happened. Of opinions about what has happened, what should happen, and prescriptions ('Instructions') of events that will happen. All this is of course some kind of documentation.

You are correct about your metaphor.
But many people want to write and read in Latin.

not if their natural language is 20th century english!

In a services environment this will be up to the actors that will make use of the services.
They will speak Latin when they want to or OpenEHR (EN13606) when this fits their needs.

whatever language they speak, it is unlikely that they will want to speak a mutually foreign language imposed upon them by the postal service, when they have standardised languages more closely fitting their communication semantics and systems.

- thomas

[thomas.beale]

Surely it should be possible to come up with some agreed high level ontologies and implement systems that support this level of ontology without being too prescriptive in defining the lower levels. It is then possible to refine the concepts through refining the business modelling they are based on and the systems that implement them. As this is achieved the next layer of ontological definition for important processes will identify itself. At this stage, in the area of Primary and Community Health, Ambulatory Care and Chronic Disease Management (my particular areas of interest) I believe that this approach translates into a focus on ontologies AND SUPPORTING INFRASTRUCTURE (sorry for yelling!) for

Patient/Client (Identification, digital certificates, basic demographics, possibly allergies, etc)s

Provider (Identification, digital certificates, speciality, qualifications, etc)

Service (context of the provider - service type, location, organisation etc.)

Communications activities (referral , orders, etc and their responses)

this is the sort of stuff many people are working on. Some are working in the archetype world, others are working in the HL7 RMIM world.

I believe that the required descriptions are essentially there in both the the openehr and HL7 RIM ontologies. My real problem is that I don't see anyone in the openehr mailing lists clamouring for the infrastructure initiatives required to support the broad implementation of ontologies at this level. There is something of the chicken and egg about this (how can we define the required infrastructure without the ontologies) I would argue that the detail of these ontologies will change for many reasons, including responses to changing healthcare practice, government policies, etc. and we should get on with implementing an agreed minimal set of directories, identification schemes and services in the above areas as basic infrastructure based on simple (minimalist even) high level ontologies. This would provide a platform for getting on with the more detailed work of refining ontologies in specific contexts. I realise that the issues of implementation are specific to particular jurisdictions, and it is possible that many of you are defining your ontologies in just the manner I am describing. As an Australian, I wonder what our role in this is given that we don't have any of the required infrastructure in place - nor any apparent source of funding to support its development?

well, actually, some of the instructure is being built in Australia (as it happens) but for international use. We have a large initial set of archetypes (GPCG project 2005) http://oceaninformatics.biz/archetypes/, and the beginnings of an ontology repository at http://www.dualitysystems.com.au/archetypefinder/archetypefinder. The interesting thing about this latter one is that it is not a normal screen form, it is dynamically generated from available meta-data from existing archetypes in the database. This is just a taster of course - this kind of application has to get a lot more powerful to fulfill the needs of a large community of collaborating authors.

I realise that this may appear to be a simplistic approach but I feel that it is important not to lose sight of the real goal - we want to build useful systems to support service providers in health care - all of them, from providers of needle exchanges, drug and alcohol counselling, home help and meals on wheels to general practitioners, respiratory physicians, orthopaedic surgeons, medical researchers and epidemiologists. In order to do this effectively, we should be wary of biting off more than we can chew. When it comes to meeting the needs of the diverse range of actors and actions found in healthcare, we need to start by agreeing on very simple generic concepts, implement them, and work our way down - rather than diving in to the detail while trying to keep the 'big picture' in mind. This is not intended to denigrate such efforts, but rather to try and encourage an environment where they can flourish and really make a difference.

I don't thik we have any difference of vision here. The openEHR reference model is designed to be as simple as possible (in the Einstein sense); it has about 80 classes including all the data types. But that's it - there is no growing collection of data schemas.

- thomas