Hi David,
well, this is an issue that I suspect we will continue to disagree on, but I do welcome the opportunity of discussing it further, so thanks for responding in such detail...
David Markwell wrote:
Thomas et al
The point you make here about the CEN ENV13606, HL7 CDA and HL7 RIM is
one I have heard you make before. I always refute it whenever I have
time so here I go again ...
HL7 RIM is a way of representing clinical information to be
communicated. The naming of the class "Act" leads to view that this is
to do with process rather than documentation. However, when you study
the definitions and use cases you find that HL7 Acts are prehaps poorly
named but actually refer to class constructed to convey documention
about things that have happened, may happen or are planned to happen
etc. They are documentation not representations of process.
I would say that the RIM describes "things in the real world" - it is about process quite clearly - that is the whole foundational basis for it - i.e. the subject / verb / object model of understaning past, present and future events in clinical reality. It is a very general and powerful model of this. But - it was never designed to be a "model of documentation", and is missing typical features from the documentary paradigm (while containing features not appropriate to documentation). Models of documentation are agnostic on the nature of the thing they document, and include such features as are found in ENV 13606, CDA and the GEHR series of models, e.g.:
- folders
- headings / organisers
- entries (CDA, openEHR) or clusters (CEN) - generic low-level data structures which can document anything
- version control
- comprehensive context of recording data
In the case of the latter, the RIM has some of this, but does not distiniguish it clearly from context data of actual clinical practice. These need to be distinguished, because the acts of _executing_ care and documenting them - are different; the former will always occur, but the latter can vary quite considerably. If these two issues are mixed up, it becomes difficult to tell anyone _only_ what happened in the clinical setting, without irrelevant details of people's interaction with computers, paper or other media. It also makes it more difficult to use documentary models with other models of content such as workflow.
CEN ENV13606 consisted of four parts. Of these the first part was high
level architecture and the last was about specific architecture. The
entire focus (and I speak with a little authority as the leader of the
fourth group) was on communication.
(don't worry, I hadn't forgotten!)
Indeed the word communication is
part of the title of the entire ENV13606 standard.
That's right, but the model is still based on a model of documentation, not of some particular class of real world phenomena, such as process, workflow or state.
The GP2GP Project is using the ENV13606 architecture but rather than
expressing this is a separatist manner is seeking to apply the HL7 Data
Types and classes. This is not just for the fun of science but rather on
the basis that EHR communication is one of many types of communication
flowing between clinical systems within the UK. The idea of migrating
these to a common implementation technology specification is the primary
driver in applying the HL7 methodology.
well - I have to say I cannot see any reason for this - there will always be a lot of different ways to talk to the EHR. Two EHR systems talking should use the most natural way of doing so, which might be EHR extract over Corba, SOAP or .NET, or it may be middleware based communication between the systems, in which case no messages at all are neeeded, including the customised HL7 style messages (as Wes Rishel calls them). There are a lot of systems I have seen presentations on recently in Germany which have this kind of communication but don't try to use HL7 messages between them. CDA is a much more common approach in the HL7 flavoured world, while EHR Extracts are also used commonly.
There is nothing wrong with HL7 messages - jsut that they are not really applicable when the communicating systems already have an internal information standard and definable/defined interfaces. In a future of shared community networks, no messages at all will be passed between EHR systems inside the trusted boundary.
There have been problems in this
approach but crucially none of these relate to any supposed conflicts
between the objectives of the HL7 RIM and ENV13606. It would seem such
differences are at worst purely theoretical in nature. From the
perspective of representing the core structured and coded semantics of
current records used in the UK the application of HL7 methodology has
resulted in a more robust approach than the ENV12265 or ENV13606 work
alone.
as far as coding goes, I cannot comment, and am sure you are right, but as I look over the GP2GP RMIM, I see many HL7 attributes that one has to search for a meaning for, and that do not correspond to what is a systematic understanding of a document structure (i.e. where to systematically put various kinds of attributes). A simple example is mood - I think it makes sense in messages, but no-one to my knowledge has suggested it go in any EHR models, including in models such as InterMountain Health Care, where moods correspond to Entry types (observation etc) just as they do in GEHR/openEHR.
I am of course mindful that no-one originally developed a systematic theory of things such as context and change control, and it is only recently that we have begun pulling such good design practices together for use with EHR models; it would be unfair to expect to find them in earlier models (including all the ones I had anything to do with...). Many of the good ideas we have documented of course come from HL7 and no doubt will continue to do so. But the "problem of the EHR" remains, as so elegantly stated by Ed Hammond in Berlin a few days ago at Eurorec in his presentation "What if we really had an EHR?".
HL7 CDA has three levels. The first of these is purely documents in the
marked up text sense - and it is the only one realised as a standard so
far. Level 3 is now under debate and Bob Dolin's excellent proposals for
this express the structured content of the record using the components
from the same HL7 RIM that we are using as the basis for GP2GP. Indeed
Bob's proposals have the appearance of a genericised version of the
GP2GP model. Certainly there are some points to discuss between them but
the two approaches are convergent rather than in any sense truly
distinct let alone divergent.
I also don't think that the "3 layers" are so important; what is important is the semantics of documentation, namely Document/Sections/Entries/structured content/data types. This is the same schema as in the EHR models, and we have begun a detailed attribute level analysis (you can see a precursor in the presentation http://www.deepthought.com.au/health/HL7/ehr_cda_tb_berlin.zip if you are interested).
I stress again the focus of HL7 RIM and ENV13606 and the GP2GP project
are communication. The merger of the methodologies has been helpful and
fruitful. I understand the general nature of some theoretical comments
made on the openEHR list. However, for all of us the challenge with
limited time and mental bandwidth is to give adequate detailed
consideration to the points of commonality.
I appreciate the whole business of timing, and have perhaps not said that often enough, but you also recognise the right for people to continue talking about "how to make things better" I hope...
Thus Thomas's observations about the "correct mapping of HL7 Acts" is
correct in so far as it goes but incomplete in that a composite of
recorded events (aka an entry) can also be safely and effectively
represent in these structures. This mapping is the way that CDA and
GP2GP both use and in both cases it seems to be fit for purpose.
what I meant was that any complex structure of Acts and Act-relationships (+ participations etc) should be mapped to Entry and Link networks - as long as the original structure is about clinical or other real world happenings - this can work nicely even if the orginal message data is some very complex network of events in a surgical operation.
However, if it is full of acts which are really "Folders", "Compositions", "Sections", and documentary relationships between these, then it is going to make it unnecessarily hard to write the software to convert such messages into a disciplined form for use in EHR systems. I know you mightn't think so in the context of the current GP2GP project, but in the context of EHR systems generally I think it will be a problem; certainly it looks problematic from the point of view of the HealthConnect project in Australia.
- thomas