Williamtfgoossen@cs.com wrote:
I believe there is some wrong viewpoints expressed below, and will include comments following my initials WG
In a message with datum 18-9-2005 1:47:54 West-Europa (zomertijd), Thomas.Beale@OceanInformatics.biz writes:
TB: from the openEHR point of view, the content of a prescription is in the record.
WG: This is probably from any patient record system, not exclusively the OpenEHR solution
well, it might be - I cannot comment - obviously many solutions are different in this area. I am just saying openEHR does it.
TB: The 'order' corresponding to a prescription is simply a
WG: so you agree you need some kind of communication, i.e. a message, that fulfills this notification act.
TB: This notification may be communicated in two ways:
WG: 3 ways......a,b,c, ?
TB: a] by the patient turning up
WG: clear,
TB: b) by an electronic notification from EHR source to filler's system asking for the prescription in the EHR to be acted upon
WG: Yes, so a message that holds the notification with a moodcode of request, assuming that the filler will act upon. The core dynamics of the HL7 approach by the way.
well, some code indicating 'request'. We don't use moodcodes in openEHR, since it is not based on speech-act theory.
TB: c) by an electronic message carrying the content (due to shared EHR not being possible) of the prescription and the notification
WG: or by an electronic message pointing to the content. It is clear you have not kept up to date with current Care Provision R-MIMs and clinical statement pattern in HL7. A 13606 based requirement is included, which is the Actreference. Thus a message would do as asked: notify a filler, but instead of sending content, it refers to content that the filler can look up (in EHR or earlier content loaden message, yes content can be there if required by clinicians) and act upon. Oh, yes of course, the message can hold the content as well if required for another use case.
But your message system won't point to something which is not an HL7 Act, presumably? No use to me. THere are no Act objects in my EHR system; everything in it is based on EHR models, not message models. And if you include the content, then you are definitel forcing the translation of the EHR information into an expression not suited to it. Transformation is dangerous and should be avoided.
What should happen is that the message system can deal with whatever content I have (an EN13606 message can do this easily), including both as a reference or inline, and just carry the notification information in either of those situations. Simple as that. I can do it with EN13606, but not with HL7v3 messages, because the latter is imposing its model of content on the source and sink of the content.
In the current situation I believe the majority of systems do not share EHR, due to existing and future different views on system design. Plurality will always remain the norm for EHR, so how to communicate then?
that is what EN13606 is about. But in any case, in Australia at least, the situation of every EHR being different is likely to change in the next few years.
TB: 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.
WG: Or like the Dutch national system approach, implemented on national scale from 1 January onward, with V3 medication messages, or the UK approach of v3 medication messages already operational.
here again, you are using message which force the source system into a semantic transform of its content.
TB: 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.
WG: As said this is an incorrect representation of how it really works. The HL7-speak is mainly for the message transfer, so how the notification does reach the fillers system. The message content is (or is OpenEHR archetyping about changing the content? No of course) exactly the same as in the OpenEHR approach: defined by clinicians, based on vocabulary that supports communication, especially supports the imposed meaning of the sender to be clear (e.g. for legal reasons), like the precise prescription order to be acted upon by the filler.
I don't know how you can say that; the content of the message is derived straight from the RMIM, and the RMIM is its own schema with semantic concept model mixed in. So the model of the content is clearly defined - but differently from EHR representations of the same content. I can easily point to some RMIM (on the NL health RMIM site if you like) and show exactly what is going on here. Just look at the RMIM for barthel or apgar; it is forcing the content to be a whole network of Act/Act-relationship, this numerous mood/type/class/instance/negation/propagation/... codes all over the place. It is not going to let the source system send the content in any form vaguely representing that used in the soruce system, or let's say, a standardised view of that (such a openEHR, which accommodates many EHR system representations we have looked at).
WG 2: it is really dangerous to assume that there needs to be no precisely defined content: healthcare requires precisely defined content, especially for patient safety reasons.
obviously. That's why things like openEHR and EN13606 exist; to define that content in a generic way which accommodates existing EHR systems, and to allow a layer of clinical modelling to control it. But the messaging service should definitely not be imposing its own idea of the content.
TB: It is clearly preferable if we are forced to work in mode c) that an EN13606 message be used instead;
WG: this case 'preferable'is based on wrong arguments: HL7 messages do not tamper with the content, nor do 13606 / OpenEHR. So not a valid argument! Both approaches do the job.
But they do William; unless these messages allow e.g. openEHR or CEN content to be sent inside an HL7 message as an encapsulated data item, then they do tamper with the content. THis is the big problem. The messages will force the conversion of all Entry types into networks of Act/Act-relationship; the data structures Item_tree, Item_table, Item_list etc will be mangled; the hundreds of HL7 codes (mostly with no meaning in the EHR) will have to be synthesised all over the place. And then you need to think about undoing it all at the other end. I have spent some days on analysing this in detail in the past, and there is no obvious transformation algorithm - not even in the forward direction, let alone the reverse. And in any case, having to do such transformations is really the wrong approach; the messaging infrastructure should not be forcing its own, alien design of information on the sources and sinks of data.
TB: 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.
WG: It should not necessarily be explored because it has been dealt with in the HL7 v3 dynamics, and as we are currently working on - this dynamics do work in the EHR as well, not only for messages.
well, that may be the case. But given that the problem is simple to solve in EN13606 and openEHR, I think it should be explored. In HL7, it is all mixed up in content structures which don't have anything to do with the EHR.
TB: 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.
WG: Yes, you are defining here the use case for the current HL7 v3 Care Provision D-MIM and R-MIM: these do 100% of what you want the OpenEHR to do. But of course, reinventing the wheel is better?
Not at all. If HL7v3 can do this cleanly with openEHR or other EHR content, I would love to see it. But you are the first time I have even heard anyone suggest it. Everyone knows that HL7v3 defines its own content, oblvious to the needs of the systems it purports to serve. And I don't think you can really accuse our work of being re-invention; where is the re-invention? However, HL7 is famous (even inside the organisation) for reinvention, including the following things.
* the v3 data types _ignored_ all primitive data types from
programming languages, XML, ISO 11404, OMG IDL etc, and built
their own. This has created huge problems, still not resolved (now
it is a new work item in ISO)
* methodology. HL7 has 're-invented' object-orientation in its
refinement methodology
* HL7 templates. I no longer know what is happening there, but the
TC appears to want to re-invent all the archetype work we have
done (and related, generic approaches thought of by others as
well). Note that we demonstrated archetypes in 2000 at HL7, and
every year since. More recently we were told that HL7 was not
interested in that aproach, and would try to do something with MIF
(which is HL7- and RIM-specific).
TB: 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.
WG: My suggestion would be to follow the Dutch suggestion to CEN for 13606 improvements: which is not only to put in a phrase that it is harmonized with HL7 v3, but actually use the Care Provision D-MIM / R-MIM set for a] explaining how the very abstract 13606 RIM, which is not harmonized with HL7v3 RIM despite the MoU, can be used for real patient care, and b] include the dynamics which has been found to be lacking in the OpenEHR and which is carefully / research and experience based modeled in HL7 v3.
But why would the 13606-1 information model be harmonised with the HL7v3 RIM? The HL7v3 RIM is not designed for EHR, and in any case is full of problems of all kinds (ontological and technical). EN13606 and openEHR are driven by EHR requirements and are fair representations of them. They are also quite simple and vey generic. I don't think anyone would describe the RIM as simple.
TB: 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.
WG: this is a real error in thinking, Thomas, you really need to think this through again, because you make absolute wrong assumptions here, resulting in a wrong judgment of the HL7 v3 messages.
??? Please indicate the wrong assumptions.
I agree with you that the EHR and related systems are examples of sources of information. I define the information here then as knowledge represented in the fields of the EHR (or if you like archetypes, organization of archetypes, entries, documents), filled with concrete data about a particular patient (so, baby Michelle, born Sept 17, 2005, temperature = 37 degrees C, APGAR score = 7, MD diagnosis = respiratory distress), and expressed in semantic meaningful wording or coding (e.g. for temperature, the archetype on www.zorginformatiemodel.nl, APGAR score from OpenEHR website, and P22.0 from ICD 10 see, http://www3.who.int/icd/vol1htm2003/fr-icd.htm ).
I am afraid that the way you comment on HL7 as not content free is pertaining to your wish to not use such standard vocabularies.
??? I think you are missing something here William; openEHR is all about using standard vocabularies; that is what the archetypes are for in a sense - they control the use of standard vocabularies. All of those ICD10 codes you require for an Apgar score appear in the binding part of the archetype. Not only that, but you can have multiple bindings to the same semantic structure, in case not everyone wants to use the same vocabulary. This capability is one of the key offerings of archetypes: flexible integration with _multiple_ vocabularies (even inside the same archetype) and multiple languages.
HL7 does not at all require semantic translations. It is the clinicians using different (agreed, not OpenEHR based) EHR systems that use different vocabularies. However, then the problem is on the clinicians level to agree upon the semantics. It makes absolutely no difference if this is in the framework of EHR development and use, or of messages. Any other suggestion ridicules clinician input and difficulties of defining the semantics in health care, which is much much much more complex than having an archetype agreement between 2 EHR systems.
Ah - I am starting to see why we are at-cross purposes. You are reading the exprssion "semantic translation" as if I meant vocabulary translations. I don't mean this at all. Actually, vocabularly translations are one of the things I think there is the least trouble with accommodating, since archetypes support multiple bindings to any vocabulary.
What I mean by "semantic transformation" is to do with the translation between information models - i.e. different class and attribute structures; and also to and from HL7's structural coded attributes.
<aside>
Consider: there are in Act and Act-relationship a collection of attributes such as code, class_code, mood_code, and status_code which are used to indicate what the instance really means. There are another 11 coded attributes whose meanings only sensibly apply in some small subset of descendant classses. The result is a combinatorial explosion of codes, creating a massive multi-dimensional space. For example, consider the combinations of just 4 coded attributes (in ballot 7, mid 2004): class_code (61 values) x mood_code (13 values) x code (too many too count; estimate 200) x status_code (10 codes) = 1.58million. If we start adding in the other codes, this will quickly multiply to far greater numbers; including the codes classCode, moodCode, code, negationInd, statusCode, InterruptibleInd, levelCode, independentInd, uncertaintyCode and reasonCode, it becomes just over 3 billion; if we add in priorityCode and confidentialityCode, it becomes 810 billion.
I have never seen an object-oriented model take such an approach in 20 years of software engineering.
</aside>
In summary, there is no clear way to translate EHR data in and out of HL7v3 RIM-based data. When I say these are semantic transformations, what I mean is that the meaning changes. And that is definitely the case; you are trying to get data defined by one ontology (e.g. the openEHR reference model or some other EHR model) into a form defined by another - or should I say many others - there are multiple RMIMs, each its own model of something.
HL7 v3 messages do no semantic translations, unless wanted by clinicians to get their content exchanged. HL7 v3 messages only do syntactical things if system A (sender) operates different from system B (filler). Translation is important from GP system using ICPC referring a patient to a hospital using ICD 10 for the same diagnosis. However, the GP EHR will use the ICPC for decision support (guidelines, yearly calls for vaccinations etc), where the hospitals EHR will probably use the ICD for additional functions (billing, national statistics). So it is not HL7 requiring any translation, but the functioning of health care at large in general and knowledgeable caring for the individual in particular.
yes - here you are talking about terminology transformation. We can deal with this I think. The problem area isn't the external vocabularies; it is the actual information models of HL7 - the RMIMs; they are in themselves semantic statements of content, incompatible with models of such content in other systems.
So to the last points: you said something I cannot agree more with, which is that: "messages should be able to carry whatever content they require". This is THE BASIC PRINCIPLE of the HL7 v3 messages.
Unfortunately it is not, and has never been. The basic premise of HL7 since version 2 (and in fact any message-oriented solution, e.g. EDIFACT) is to define standardised messages, on the basis that nothing can be assumed about systems. With EDI and HL7v2, this was not a bad assumption, and in fact both kinds of messages continue to do a useful job. In pathology, v2 messages have actually been very useful, since their design actually helped pathology lab companies define their own information where they had none. This is probably still the case, as HL7v2 is still going strong in many countries. But no-one has ever suggested using v2 messages between EHRs, or from the EHR, or from GUI app to applications, or in many other places; what it is good at is predefined lab messages. And all of this was designed for 20 years ago, when there were little/no health information models. Things have now changed: there has been 20 years of research around the world into how various kinds of information should be structured. To name just a few examples: Riche, Nucleus, Gehr, Danish G-EPJ, Corbamed, openEHR. And that does not touch on the hundreds of vendors, conferences, and other activities in this space.
HL7v3 is a different way of creating messages, but in the end it is predefined messages, same as v2. But now we are in a different era. There are well-designed models of content and service interfaces all over the place. So the applicability of messages which are still trying to enforce their own content is very questionable in my view. In pathology and imaging it might be alright - and for those situations, the users might as well stick with v2 - they already have working solutions. But in other areas, it is not true. But now we have the RIM and RMIMs trying to force how EHR information should look while being transported somewhere. Quite apart from the fact that it obliges a new data schema with every single message type.
Think of it this way. If we have an EHR system and say a pharmacy system, based on their own models of content, and the object is to a) make some information visible to the pharmacy - the contents of a prescription and b) to notify the pharmacy to do something about that, how would you do it? You would make the EHR information available and you would send a notification. But you wouldn't contort it into another form which has no particular meaning for either system, just to do the communication.
TB: 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.
WG: Hopefully they do, to keep patients alive and safe!!
TB: 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.
WG: maybe I am lucky of not having seen this Monty something. A message should impose semantics, which is what HL7 v3 messages are: filled with clinical content, to ensure that the receiver can determine the meaning as exact as possible.
No, in general, a message should not impose semantics: the semantics of the information are defined by the sender and receiver systems, and the relevant standards and architectures. Think of it this way: the TCP/IP protocols are not forcing you and I to have this conversation in strange strings of bytes or sub-packets. We are able to have this conversation because the relevant protocols are content-independent. HL7 "protocols" are not: they are content definitions mixed up with protocol/notification definitions, mixed up with ontological definitions. You either buy into the whole lot or nothing.
TB: 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.
WG: Yes, this agnosticism renders it potentially dangerous for healthcare. We are spending millions now to sort out that clinical content is exchanged correctly, e.g. to prevent the hundreds of thousands medication errors. Especially within the 13606 and OpenEHR and HL7 v3 environment the exchange format should be secure enough for any clinical content, and the content needs to be defined by clinicians, preferably in a format that can be used in any technology, not just only one vendor lock in system as OpenEHR currently is.
William, openEHR is not a vendor. It is an open community, with open published specifications. There is no "lock-in". Saying openEHR obliges some kind of lock-in is the same as saying HL7 obliges "lock-in". Clearly the use of any standard implies accepting what that standard has to offer; but this is not the same as being locked into a vendor. I would ask you to be careful about any such misrepresentations. Even though I don't agree with many design characteristics of HL7, I certainly have never claimed it represents "vendor lock-in".
There was another suggestion on this list to work on the reusable bits and pieces that need to be documented and exchanged in a standardized and preferably world wide agreed format.
1. Person demographic data like, name, date of birth, gender, perhaps a social security number if legally possible, and those other things that make an individual an individual and only that individual.
2. Patient related administration data of a person that tend to change over time, like addresses, insurances, institutional defined identification numbers, which can be zero to many.
3. Relationship based administration data of the person, e.g. for next of kin, children etc, with a focus on contact addresses, emergency phone numbers and so on.
4. Persistent clinical data: those data that are specifically for health related issues and that will probably not change over time and everybody needs to know: allergies / intolerances / blood group, body length.
5. Clinical statements of a person; the smallest molecular items of information that have a meaning in the health care arena. Probably the archetype list of OpenEHR and my set at www.zorginformatiemodel.nl fall in this category.
Look, I don't disagree with all of this. What you need to understand is that the appropriate way to model this kind of content is not inside message schemas, it is in clinical concept models which are independent of schemas. I am sure that all of the people who attended all the relevant meetings to generate all these definitions did good work. Unfortunately it has been done in the wrong kind of framework. But it can still be re-used, no problem with that. The openEHR clinical experts have no intention re-inventing all this stuff. What they do want to do is have an open framework and tools suitable for doing such modelling and evolving those models in time. This requires having a technical approach with sufficient semantic power to do so, and tools to match. This is what our effort has been about for many years. Ideally, HL7 would actually start to participate in this community and contribute to the work going on in this area. Instead, they have chosen to do it in their own way, with a framework and approach not designed for the purpose. The whole reason there is so much interest in archetypes is because they do provide a powerful, flexible and generic framework. I did a presentation in 2002 at an HL7 WGM on how to use the tools and approach to do the same thing for HL7. This was ignored. What can I say? Further, it is clear that there is serious internal inconsistency, since RMIMs and HL7 templates (when defined) will be able to express the same clinical concept in incopmpatible ways.
HL7 v3 provides standards for already the following:
1. CMET E_Person has already a good set of attributes for this
2. CMET R_Patient has already a good set of attributes for this
3. Most can be met in other HL7 v3 artifacts, new use cases will will hosted without any problems as the case is clear.
4. The allergy / intolerance R-MIM of patient care covers now almost all relevant components / attributes and work on semantics is underway.
5. These can be expressed in the clinical statement pattern / care statement pattern of current HL7 v3 (hypothesis: all?, if not challenge the model to become inclusive, not blame it).
William, people have been coming to HL7 for years challenging the RIM and related models. There are numerous problems with them, but the common experience has been of pushback. That's well known amongst many affiliates. The RIM and v3 data types have remained seriously problematic. Some in-depth papers on these problems will be published soon, so you will have all the evidence you want.
A bit clumsy is still that the R-MIM / CMET / archetype / template discussion has not been solved yet, but we are very close in doing so and get e.g. an XML expression that would allow hooking in the HL7 v3 message, in the CDA and in the 13606 / OpenEHR entries. From the clinical perspective the latter is merely a technical task to have it work in a open standard like HL7 v3 or a vendor / system specific approach as OpenEHR.
Unfortunately it is not at all trivial, and may not even be feasible. It is easy for software and modelling experts to look at all these models and see the major incompatibilities. You cannot just say that it is a minor technical problem to be solved with a bit of Xslt or whatever.
Just to name a list of what is currently available in R-MIM format with explicit clinical input on knowledge, variables, terminologies, value sets:
- vital signs all and length and weight
- physical exam generic
- urine function
- assessment
- history
- family history
- neurologic exam
- nervous system exam subset
- social aspects
- communication
- walking ability
- somatic problems / dysfunctions
- ADL functions open questions
- Barthel index
- psychologic and psychosocial factors
- Mini Mental State exam
- CES-D depression scale
- FAC (Functional ambulation categories)
- Frenchay arm test
- Fatigue scale
- 10 meter walk test
- RAP protocol
- Bamford stroke classification
- Glasgow Coma Scale
- Berg Balance Scale
- Apraxia scale
- consciousness assessment
- checklist admission in hospital
- COOP WONCA scales
- coordination
- cortical functioning
- upper and lower extremities assessment
- ergotherapy assessment
- physiotherapy assessment
- logepedia assessment
- partly: nursing assessment (use of Gordon's functional health patterns as organizers of content, not determinants of, so no super imposed structure, but easily adaptable)
- use of aids
- encounter tracking and planning, e.g. preventive care
- meningeal problems
- modified Asworth scale
- modified Rankin scale
- Motricity index
- NIH stroke scale
- motor functioning assessment
- pain score (VAS style currently, full assessment underway)
- star cancellation test
- sensibility assessment
- smoking, alcohol, drugs use
- reflexes assessment
- trunk control test
- feeding status
- description of the home (e.g. to determine place for discharge of stroke patient)
this stuff is all great - I think your (and others) work is brilliant. Only one problem: it is buried in a framework of HL7-specific codes and structures, and suffers terribly from the lack of data structures (spatial and timing), and many other things. Not to mention, the coloured box diagrams are very hard to read. It can be re-expressed very cleanly, and more flexibly in archetypes. We should cooperate on that. But there still may not be any easy path to data interoperability because you cannot get away from the fact that HL7 is forcing the use of its own data schemas and models on both the clincal modelling exercise, and on the communicatig information systems. And every single clinical model (i.e. each thing you mention in the list above) is a new data schema in HL7. In openEHR and other generic approaches, there is only one data schema. Full stop. This has profound consequences for software solutions.
Al have a specific format that defines the purpose of the scale / assessment, the variables, value sets, codes, the method for use, interpretation, literature, an HL7 v3 R-MIM a systematic listing of a mapping table with variable, place in HL7 v3 D-MIM / R-MIM (the RIM itself makes no sense here, the format for EHR and Message is key), datatype, value set, cardinality, unique code (to keep semantics OK), and often examples of scores or result of the observation. Further, we have in some instances an XML representation (example message format) and for Barthel an OpenEHR archetype. Several have organizers or batteries, which allow to group sets in larger sets.
I don't argue with any of this; all of these are what archetypes were designed for. However, you can do a lot more with archetypes - the constraint semantics are significantly more powerful. Plus you can link to as many vocabularies and languages as you like.
The sensible thing to do would be to work in terms of archetypes and generate message definitions from that. I don't know how easy to do that would be, given the impositions of the RIM, but at least it would be correct direction.
Some in progress:
- DSM IV scoring on 5 axis
- Apgar score
- meals on wheels
- housekeeping as care for elderly and handicapped
- house adjustments in case of disabilities
Sure. Same as in archetype land. But doing more of this work in the HL7 will remain difficult to do and re-use, and be hampered by the modelling framework. To provide just a single example: In a microbiology result, in an HL7 RMIM, I am forced to define mood code on every node of the result - 45 nodes. Same for all the other attribute codes coming from the Lab Obs variant of Act. That's hundreds of meaningless clinical modelling decisions to make. Whereas in an archetype, it only has to be done once for the whole result.
Some in preparation: diabetes monitoring of complications like foot, eyes, renal functions etc. follow up visits, and much more.
In preparation: European EPUAP guidelines for pressure ulcer risk detection, prevention, wound descriptions, wound care.
And many more to come.
I feel sad that so many things are being done in such a hard way!
Instead of arguing the case for or against HL7 v3 / OpenEHR, I prefer help in analyzing and improving what we currently have, suggest improvements and corrections, and to work on a technical representation that suits many systems, especially that does not worry about HL7 v3, 13606 or OpenEHR. I then leave it to the technicians that built one kind of solution versus the other to handle this clinical stuff.
We do want to work together on all this. We have offered a powerful, generic, flexible framework for doing so, designed for exactly the job at hand. Many people are using it internationally. I invite more to. Online repositories are being set up to index and store archetypes, to enable online collaboration. There is no point for us (or anyone else for that matter) trying to work with a message modelling framework manifestly unsuited to clinical concept modelling. Why do it? It just creates difficulty, invites errors, and in some cases prevents semantics being expressed.
I further would suggest the HL7 v3 versus 13606 / OpenEHR debate to be removed from OpenEHR clinical to OpenEHR technical.
For those who can read English and are not scared off by 90% of content in Dutch and pink coloured HL7 v3 Observation classes clinically organized together, the Mapping tables of the above instruments are available on www.zorginformatiemodel.nl. This stuff is copyright free and can be used. The only things I ask is to tell me if it is useful to you, and to not blame the current HL7 v3 R-MIM format. We use this because it is the only current process that leads to true XML messages that can be validated against the message schema's. I look forward to new tools that allow me concentrate on the content and that spit it out in HL7 v3 XML / archetype format.
William, what is a "true" XML message? I would love to know. We have already provided a powerful language and tools for the job you are doing. Why don't you use them?
- thomas beale