Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
Andrew Ho wrote: On Mon, 29 Dec 2003, Thomas Beale wrote: ok, I've seen these. There are multiple archetypes implied by the UoP form, and a lot of details that the form doesn't mention at all - which is fine - that's not its job; but where is the specification of the semantics of the data? Semantics = form metadata + translators definition? - How would I re-use the segment about (recreational) drugs and alcohol Copy and paste. in another form? Yes, into another OIO form. - Or the cancer-related questions? Same - copy and paste. what would I copy and paste - what is the boundary of drugs and alcohol questions? - In particular, how to ensure the data on these same sections is the same when generated by different forms? Don't change them after you paste. but rugged individualist form writers won't live with that; you've already told us so - Where is the entry validity specification? Input validation definitions are part of the form metadata. ah - the mysterious form meta-data... - Where is it specified what parts are mandatory to fill in and what parts not? Mandatory vs. optional is currently not a separete question item attribute. Maybe it should be - what do you think? well...it's pretty common that some items on a form are mandatory and some not, if you are going to generate data that is even slightly meaningful. Questions usually come in groups and sub groups; usually whole groups become mandatory on the basis of the answer to another question (e.g. any allergies? = yes = now describe the allergies in multiple occurrences of an allergy characterisation sub form). Andrew, I really think you need to consider doing some design work, instead of providing endless simplistic responses to technical questions, which in general are non-trivial to solve properly. - thomas beale
Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
On Tue, 2003-12-30 at 09:55, Thomas Beale wrote: Andrew, I really think you need to consider doing some design work, instead of providing endless simplistic responses to technical questions, which in general are non-trivial to solve properly. Although it is valuable to ask questions about OIO and openEHR in order to better understand what the two systems/frameworks can and cannot do, there also needs to be mutual (and I stress mutual) respect for the different philosophies behind these two projects, and the different world-views of their creators. Andrew tends to laissez-faire individualism, and has created a tool which gives individual clinicians a huge amount of freedom when it comes to collecting data. The openEHR group tends more to well-structured collectivism which nevertheless preserves some freedom to experiment and be creative - certainly not a Stalinist approach, more a form of well-behaved anarcho-syndicalism, perhaps. Given these clearly divergent starting points, it probably serves no purpose to exhort Andrew to ...do some design work, just as it serves no purpose for Andrew to remonstrate that openEHR is too complex. No-one is forced to use OIO to manage their data, thus the lack of formal design documents shouldn't worry people to whom such things matter. Similarly, if openEHR documents seem too complex, or the framework too restrictive, then don't read the documents and just ignore the framework. The world is a big place and there is room enough for both, and the existence of one does not diminish the other. Or at least that is how most of us see it. -- Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0 signature.asc Description: This is a digitally signed message part
Generating income as a reason for orgainsed entry in the EHR[WAS: Re: hub, spoke, new Esperanto for healthcare, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
On Monday 29 December 2003 22:06, Thomas Beale wrote: Experience with structured entry systems on the other hand (mainly in Europe) has shown that the computability of the data is much higher. I agree that computability of structured data is much higher. That is why the OIO project seeks to deliver structured data but allow the end-users maximal control regarding how the data are structured. but allowing end-users to do this is almost a guarantee that the structured data will not be computable; One likely reason for computing that data is because income is generated (via billing) from the recording of certain specific codes/concepts in the note. Those dependent on that income may well wish (those working for them) to have a very specific way to record that strongly encourages that use of that externally developed and defined code/concept/archetype. A collection of examples are those in the next spasm of Primary Care in the NHS. -- Dr Adrian Midgley I use Free software because it is better http://www.defoam.net/They carefully didn't ask.
Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
On Tue, 2003-12-30 at 09:55, Thomas Beale wrote rather tartly and I smiled but won't repeat it. Tim Churches chipped in there also needs to be mutual (and I stress mutual) respect for the different philosophies behind these two projects, and the different world-views of their creators. I agree. And that includes the mutuality and stress on it. The mass of detailed work done in Open EHR is vastly impressive, and is fit for its purpose but the ad hocery of OIO also has value. It is clear to me that for a large-sale system to do (a sizeable subset of) everything ad hocery won't suffice, and this is partly from being in the context of a large healthcare system that has a considerable collision between laissez-faire regulated capitalism, anarchy and State constraints and has for the last dozen years been being warped into a significant degree of concordance on the clinical thesaurus and other organised cooperative tools at costs significantly greater than they could be if we had known then what we know now. Large-scale deployed systems need to have layers of subtlety to them, and it is a mistake to remove the capacity for ad hoc work from the users, as it is a mistake for users to use that to re-invent and diverge on what has been done once already. I've found the dialogue interesting, but I can imagine how frustrating the mismatched vocabulary and world models can be for the participants. -- Dr Adrian Midgley I use Free software because it is better http://www.defoam.net/They carefully didn't ask.
Re: cancer registry example, Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
On Mon, 2003-12-29 at 20:18, Andrew Ho wrote: Case of Cancer will use a response/itemtype with action=pickone_from_form. Specifically, this response/itemtype will retrieve all Cases of Cancer for this patient and allows the selection of one of the cases as answer to the Case of Cancer question. I wasn't able to get LiveOIO working on my son's PC - not enough memory perhaps (only 128MB), so I couldn't explore this directly. However, I found this explanation: http://sourceforge.net/docman/display_doc.php?docid=17710group_id=9295 and now understand the solution proposed. Basically, OIO automatically associates every form instance with a patient, and within the context of a particular patient, if the user wants to associate a form instance with other form instances, they need to manually choose the target of the association from a list. This list can be set up so that, in our example, only cancer cases for the patient in question are shown in the list. So if I were completing a histology results form for a patient with three cases of cancer, I would need to manually choose which case the histology results relate to when completing the form. Whether such an approach is adequate, or too awkward and error-prone to be useful, really depends on the circumstances, I suppose. -- Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0 signature.asc Description: This is a digitally signed message part
Re: cancer registry example, Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
On Mon, 29 Dec 2003, David Forslund wrote: ... Correct, each form-instance is linked to a patient. Forms (blank forms / metadata / in the abstract) aren't linked to any patient. But there still needs to be relationships and contexts for forms. Right. Aren't there linkages between forms in the abstract, too? Dave, Yes, since Form A can contain a quetion item that uses a pickone_from_form response that depends on a question item on Form B, Form A and Form B can be linked via this question item: Form A Form B Cancer Case Number --- Cancer Case Number Histology Date discovered Staging Cancer name In other words, can't I have a complex form? We don't have simple vs. complex forms. OIO forms are rather flat and quite simple. However, this issue has been raised quite a few times by Alex Chelnokov. OpenEHR's organizer archetype provides an useful mechanism to model hierarchical relationships between attributes within each archetype. If we add complex forms to OIO, we will probably copy OpenEHR's archetype organizer design (page 30, http://www.openehr.org/downloads/archetypes/archetypes.pdf). What do you think? Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
Re: cancer registry example, Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
On Tue, 2003-12-30 at 15:50, Andrew Ho wrote: Yes, since Form A can contain a quetion item that uses a pickone_from_form response that depends on a question item on Form B, Form A and Form B can be linked via this question item: Form A Form B Cancer Case Number --- Cancer Case Number Histology Date discovered Staging Cancer name This is fine - the only wrinkle is that the end user has to specify the relationship manually using the pickone_from_form question on Form A. Nevertheless, it is probably an acceptable solution for individuals or very small groups who are highly motivated to collect small amounts of data very carefully, although even then there is a risk of accidentally choosing the wrong Cancer Case Number. In other words, can't I have a complex form? We don't have simple vs. complex forms. OIO forms are rather flat and quite simple. However, this issue has been raised quite a few times by Alex Chelnokov. Complex forms which allow master-detail or parent-child data entry are the solution to the above problem. However, they can be quite tricky to implement successfully, in a general manner, using plain HTML (or HTML plus common JavaScript) - which is required if client requirements are to be kept minimal. Using client-side Java or soem other GUI framework (including browser plug-ins etc), the programming task is simplified but the deployment task made more harder. OpenEHR's organizer archetype provides an useful mechanism to model hierarchical relationships between attributes within each archetype. If we add complex forms to OIO, we will probably copy OpenEHR's archetype organizer design (page 30, http://www.openehr.org/downloads/archetypes/archetypes.pdf). What do you think? Do you mean organiser concepts, as opposed to content concepts. I don't see how this particularly helps with specifying entity relations. I think you might get more value out of the QUANTITY attribute and the A_RELATIONSHIP class (p36 of above reference). -- Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0 signature.asc Description: This is a digitally signed message part
Re: cancer registry example, Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
On Tue, 2003-12-30 at 16:36, Tim Churches wrote: ...the deployment task made more harder. Err, much harder. -- Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0 signature.asc Description: This is a digitally signed message part
Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
On Sun, 28 Dec 2003 13:12, Thomas Beale wrote: exactly - this is the problem of N^2 translation that HL7v2 has. I was just saying that Andrew's statement that HL7 has failed is not totally correct; and regardless of the shortcomings (of which I can be as critical as anyone else), there are quite a lot of implementations, and there is a measure of success. It's been a step on the path, and a lot of things were learned. A lot has been learned, yes. But Andrew's statement - if we only look at what is actually available AND in use today - is correct: HL7 has been en exteremly expensive failure so far. A failure for more than a decade, that is. Current development looks promising and I wish them wholehearted success - but in one aspect they haven't learned from their past errors, and I consider this non-learning a gloomy sign: that is, they don't publish their work freely. You have to become a member to access their standards. It does not matter that membership is cheap - even a cent a year would not be acceptable fpr the very reason that a standard cannot be a practical and ubiquitously accepted standard (such as POP3, HTTP, HTML) unless the specifications are freely accessible to anybody. Unless they start understanding this crucial issue, I reckon they are doomed. No matter how much more money governments throw after them. The world in general is not very fond of such closed gentlemen's clubs, and end user tolerance for such behaviour is close to zero nowadays. Horst -- On two occasions I have been asked [by members of Parliament!], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. -- Charles Babbage
Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
On Sat, 27 Dec 2003, David Forslund wrote: How do I use OIO forms in a non-OIO application? Dave, You can't. If an application uses OIO forms, then it is an OIO application. :-) In other words, I don't want to have to run Zope to use and manage forms, and I don't want to rely on having to get to a remote OIO server to get a form, since I might be blocked by my firewall (as in the case of the entire VA). Try LiveOIO, the Knoppix-based boot disk that runs and installs OIO. What is the platform and language independent description of an OIO form? form item name description item_number prompt itemtype /item itemtype name description action choice code /itemtype /form Couldn't that be an OpenEHR archetype or an XML schema, or an HL7 CDA? Yes, that's the idea. In this case OIO might be used only has a way to author an archetype, OIO can be a web-based tool for authoring OpenEHR archetypes / OIO forms and also render/collect data via these archetypes(+templates) and forms. although there needs to be a place which maintains the official structure of a form, such as HL7 or some other body. Maybe - or end-users can simply upload forms into the OIO Library to be index and shared. Can you send me an example OIO form that I could simply use in my JSP web application? form item nameGender/name descriptionself-reported gender/description item_number10/item_number promptGender?/prompt itemtypegenders/itemtype /item itemtype namegenders/name descriptionphenotype gender/description actionpickone/action choicefemale,male,unknown/choice code2,1,0/code /itemtype /form Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
Re: hub, spoke, new Esperanto for healthcare, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
On Sat, 28 Dec 2003, Tim Churches wrote: ... Converters are necessary evils. But having spent far too much time writing converters (80-90% of any epidemiological or statistical study is spent in data management and data preparation, which usually means writing custom converters), I am **very** interested in any means of having to write fewer of them in the future, not more. Perhaps more re-use and more automative generation will lead to less need for custom, hand-built converters that you are familiar with? ... This like saying if we standardize English then we won't have to worry about learning new words and slangs. ... People with strong individualistic traits tend to be suspicious of standards. This is quite characteristic of many physicians and scientists. ... These may be useful - but they are not replacements for converters. Thus, they must not prevent development of an adequate converters infrastructure. I have never seen any data dictionary, minimum dataset, terminology or other data harmonisation effort which has said Thou shall not develop data converters or converter infrastructure. Never, not once, ever. Promoters of restrictive terminology tend to suggest converters are needed only for exceptional cases and ought not be used regularly. Instead of recognizing converters as a desirable part of the semantic network, they tend to see them as necessary evil :-). ... As I pointed out repeately, a constraint language is not sufficient. We also need a translation infrastructure. This is exactly why OpenEHR, in its current form, is inadequate. I agree with you here - that a translation infrastructure is needed - one that can take data collected in accordance with given metadata, and automatically convert the data into another form as defined by different metadata. AFAIK, openEHR does not currently provide that. But I have a hunch that openEHR may provide an excellent, principled basis on which to build such converter infrastructure. Maybe you would be willing to help in this effort? ... The tricky part is avoiding falling into the same trap our predecessors fell into. OpenEHR's emphasis on creating common archetypes suggest it may fall into that exact same trap. Which trap was that? Focusing on forming political structures to build and promote common archetypes/terminology rather than constructing translator/converter tools. ... To the extent that OpenEHR does not provide a translation facility, it will be rather hard for humans to create their own unique archetypes and make full use of them. Sorry, you've lost me there - what does a translation have to do with the ability to create archetypes? Lack of translation tools leads to significant *disincentives* of organized medicine to permit individual physicians the option of creating their own archetypes. ... do you mean that everyone should have their own definitions of data items? Not that they should - but that they can. With translators between them? Instead of shared definitions? Yes. Without a translator infrastructure in place, shared definitions (=restrictive terminiology) will be the only remaining option. Pretty soon, some will argue (effectively) that the solution to mutually incompatible OpenEHR archetypes will be to agree on a standard set of archetypes to use. I think the idea is to try to avoid the stage of mutually incompatible archetypes as far as possible, and skip straight to agreeing on a standard set of archetypes. Such thinking leads us straight back to SNOMED, HL7, etc. Note that mutually incompatible archetypes need not come from human error - instead, they can also be caused by lack of translators! :-) ... Information system standards reflect existing constraints, not cause them. By not providing an infrastructure to support translators, information systems such as the one proposed by OpenEHR will be far more restrictive and less semantically descriptive than free text. Organizations that choose to adopt such systems will likely place new restrictions on their physicians' ability to communicate. ... The question is _who_ should be allowed to describe medicine to computers? Should it be the priesthood of software engineers? The priesthood of elitist medical experts? Or any willing physician? That's a good question, and no-one is sure of the answer yet. That is not so. Through design-decisions that we make when we construct, test, and deply these information systems, we give clear answers to this set of questions. Certainly the priesthood model has often failed, or often been rather unsatisfactory. Surprisingly, we often do not act like we learned anything from these lessons. ... It is only possible to standardise those areas in which there is consensus or shared knowledge (or sometime shared belief). That's a lot of medicine, but not all of it. And who shall decide which fragment of knowledge to carve into stone?
cancer registry example, Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
On Sat, 28 Dec 2003, Tim Churches wrote: ... For example, the Philippines national cancer registry can create a set of OIO forms - each form describes the initial presentation of a cancer case at the time of first diagnosis. In this example, the top level clinical concept is cancer case at the time of first diagnosis - which is modeled via an OIO form. For example, the Prostate Cancer Detected form, the Ovarian Cancer Detected form, etc. Within each OIO form, there will be multiple concepts (=Question Items) that serve to describe each reported cancer case. Cancer registries are something I know a bit about, having worked in one for a while. So how would OIO handle a cancer registration system? The basic model for a population-based cancer registry is as follows: Each person in the (usually geographically-defined) target population may have zero or more cases of cancer. A person is defined by their demographic details, (name, DOB, sex, address etc) and some of these details may change over time, and these changes need to be recorded. Tim, OIO's patient ID module maintains identifiers that uniquely identify each person. Additional demographic attributes (e.g. sex, address) can be recorded in a Demographics form. A case of cancer is distinguished by time of diagnosis, tissue of origin (topology) and histology (morphology). If these attributes are the same across all cancer types under study, then it may be reasonable to record them on the same form (and apply that one form to all cases being reported). There are some additional rules relating to metachronous tumours in paired organs or the same organ (cancer of the left kidney in 1982, and of the right kidney in 1989, or multiple colon cancers appearing over tyhe course of a decade). For attributes that are unique to some cancer types, these should appear on specific forms that only apply to the reporting of those particular cancers. For each case of cancer, there are zero or more of each of the following: histology reports, treatments, hospital admissions, and various other details, and zero or one date and cause of death. Each of these should be a form: for example, a form for recording histology results, treatment (perhaps a form for each treatment type - radiation, chemotherapy, surgery, etc), hospital admission, and death. Andrew, perhaps you could sketch out a word picture of how that would be handled in OIO, for our education? Or even a rough sketch of an implementation in OIO? As above, please let me know if you like clarification for any of these. Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
Re: hub, spoke, new Esperanto for healthcare, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
Exactly! That's the goal. But to do that, we need to describe a lot of medicine to computers in a way that they can understand. This is one of the things we are trying to do. This does not need a standardization but rather a framework on which to develop, collect, information and to share them. Sharing forms is one simple way, sharing the structure on which a form should be built to allow sharing and comparison is another necessity. A good simple example is the ICD10 Procedure Coding System. The system has developed a structure to facilitate coding which makes a way a computer will understand. This may look strange initially but once learnt makes for a less verbose, simple structured way of collecting data. What do you think? Nandalal -- __ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze
Re: hub, spoke, new Esperanto for healthcare, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
On Sun, 28 Dec 2003, Thomas Beale wrote: ... Those who paint converters as evil are likely responsible for standardization failures of our past. Any information system that does not fully support converters cannot provide extensible semantics support. well, I don't think that's true - consider the 'information system' represented by a set of class texts in some library; for these to interoperate with the class texts of another programmer, there are various possibilities: - programmers A and B can collaborate to produce new or changed classes which work for both of them Thomas, In this context, collaborate is a out-of-band translation effort. - programmer B can inherit from a class of programmer A Inherit is a special form of A-to-B translator. - programmer B can use a class of programmer A (i.e. use its interface) This is re-use, not extension. Also, programmer B's ability to locate and retrieve A's class also requires translation (of B's intention mapping to A's published description). - the system built by programmer B, having no prior knowledge of the system built by programmer A, might try to talk to it and use a dynamic invocation interface to ask it what its operations are and then try and make sense of them and call them I suggest that converters are analogous to the last category here; the first three categories represent some kind of a priori collaboration. If you insist, you can call them a priori collaboration but they should be modeled as translators if we wish to eventually automate much of it in-the-band. ... As I pointed out repeately, a constraint language is not sufficient. We also need a translation infrastructure. This is exactly why OpenEHR, in its current form, is inadequate. as I have pointed out a number of times in the past, there is room for 'translation' of data via archetypes; all I have said is that it is not the front line approach in achieving interoperability. I differ in this assessment. Interoperability through re-use of OIO forms or OpenEHR archetypes is trivial. Our research and development focus will be on translation services. it would be interesting to see: - the constraint language definition that you propose This is the forms-metamodel, for example. - a description of the translation tools 1) Pick 2 forms, 2) define mapping between question items, 3) define re-coding/transform functions, if any. - the OIO equivalent of a systemic arterial blood pressure measurement, an Apgar result, a glucse tolerance test result, a psychiatric note, These are all single data items. They will just be Question items on OIO forms. For example (blood pressure), form item namesBP/name descriptionsystemic arterial blood pressure, supine/description promptsBP?/prompt itemtypepressure/itemtype /item itemtype namepressure/name descriptionmmHg/description actionnumber/action choice/choice /itemtype /form ... A classic case of blaming human users for inadequate information systems!!! Now, let's whip the human end-users into submission so that they won't dare question the wisedom of the perfect machines :-). Getting out of the sea of incompatible data means some kind of cooperation. Cooperation is one thing. Having no other option (to agree to disagree and then use translators) is quite another thing. ... Sure it does. What if computer software can create these data converters without human intervention? if that's true, then you in fact have some kind of systematically computable compatibility between forms, and they are not in fact completely independently created. Appearance of intelligence comes from the ability to discover non-obivous relationships between concepts :-). Completely independently created does not necessarily mean zero computable compatibility. ... Can you show how you came to these conclusions? 1) OpenEHR lacks a fully functional, open-source implementation -- No code to download. 2) OpenEHR has no translation facility (and no recognition that a translation infrastructure is central to its professed future-proof goal) -- Per OpenEHR design documents and recent discussion 3) Target audience is not any willing physician - thus it is not capable of supporting a grass-roots build-out. -- No end-user tools that support deployable archetypes/templates for data collection and reporting 4) Overly complex archetype model - unnecessarily hard to understand, needlessly difficult to implement -- why archetype model cannot be simpler is unclear -- archetype model did not come from incremental development based on real implementation experiences (that drove incrementally complex model) -- use of much jargon in documents that describe OpenEHR archetype model. If it is easier to understand, it may be easier to implement. Perhaps we should publish a comparative analysis of a very simple
Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
The same goes for SNOMED-CT. It is a proprietary standard and very expensive for poorer countries. So how can this become a standard nomenclature? Hopefully ICD-10-CM will see the light of day soon BTW ICD-10 -PCS seems very promising to me - even though not yet implemented. Nandalal - Original Message - From: Horst Herb [EMAIL PROTECTED] Date: Sun, 28 Dec 2003 18:08:53 +1100 To: [EMAIL PROTECTED] Subject: Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released On Sun, 28 Dec 2003 13:12, Thomas Beale wrote: exactly - this is the problem of N^2 translation that HL7v2 has. I was just saying that Andrew's statement that HL7 has failed is not totally correct; and regardless of the shortcomings (of which I can be as critical as anyone else), there are quite a lot of implementations, and there is a measure of success. It's been a step on the path, and a lot of things were learned. A lot has been learned, yes. But Andrew's statement - if we only look at what is actually available AND in use today - is correct: HL7 has been en exteremly expensive failure so far. A failure for more than a decade, that is. Current development looks promising and I wish them wholehearted success - but in one aspect they haven't learned from their past errors, and I consider this non-learning a gloomy sign: that is, they don't publish their work freely. You have to become a member to access their standards. It does not matter that membership is cheap - even a cent a year would not be acceptable fpr the very reason that a standard cannot be a practical and ubiquitously accepted standard (such as POP3, HTTP, HTML) unless the specifications are freely accessible to anybody. Unless they start understanding this crucial issue, I reckon they are doomed. No matter how much more money governments throw after them. The world in general is not very fond of such closed gentlemen's clubs, and end user tolerance for such behaviour is close to zero nowadays. Horst -- On two occasions I have been asked [by members of Parliament!], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. -- Charles Babbage -- __ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze
Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
On Sun, 28 Dec 2003, Thomas Beale wrote: ... Within each OIO form, there will be multiple concepts (=Question Items) that serve to describe each reported cancer case. I'd like to see examples of these forms - can you provide a URL? Thomas, The cancer forms are just examples for this discussion. They have not been made yet. However, you can see example forms at: http://www.txoutcome.org/scripts/zope/newuser/signup/forms_gallery In particular, the University of Pacific Health History form (and translations) were made by Mark Preston and myself using OIO, based on http://www.dental.uop.edu/DentalPro/Health_History_Forms/default.htm ... Contextual information on forms include 1) the fact that the data items appear on the same form 2) proximity of data items to each other on the form 3) sequence of appearance 4) inter-item dependency, if any ... I think all the items you point to are important - to gui design; ... Also important for semantic interchange - which I guess you don't agree with ? Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
On Sat, 28 Dec 2003, Tim Churches wrote: ... the Prostate Cancer Detected form, the Ovarian Cancer Detected form, etc. Within each OIO form, there will be multiple concepts (=Question Items) that serve to describe each reported cancer case. Hold on... Andrew, you are suggesting that there should be a separate form for each type of cancer? Tim, If you wish to describe each type of cancer by different set of question items, then yes - you should have separate/distinct forms for each. So in OIO data for each type of cancer is stored in a separate table? Could be - if that's what you want. On the other hand, maybe you can get away with describing all possible cancer case using the same form? Or, you can have a first form that contains common questions (across all cancer types). Then, a special form for each cancer that contains all the cancer-type-specific questions. Say there are 50 types of cancer of interest (that's an underestimate). So to create a frequency distribution of type of cancer, I need to write a query which visits 50 tables? Not at all, OIO's reporting module can do that for you. Sure it would be better to record type of cancer as an attribute on a single cancer Case form, Yes, you can do that too. It all depends on your particular clinical or research needs. and then record the particularities of each case on separate, specialised forms for prostate cancer, ovarian cancer etc. Yes, that's probably how I would do it too. It is just that I can't see how one would do that using OIO. 1) Just select a patient, select a form, and fill it out. Or 2) define a workflow that contains fillout first form, branch-on-condition, then fillout second form (selected based on answer to cancer-type question on the first form). There is a screeshot with example of this type of workflow here: http://www.zope.org/Members/aho/Open_Infrastructure_for_Outcomes/OIO-1.0.0%20released There is actually a demo workflow on the LiveOIO CD that does this. Download from http://sourceforge.net/project/showfiles.php?group_id=9295 Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
On Sun, 28 Dec 2003, Thomas Beale wrote: ... exactly - this is the problem of N^2 translation that HL7v2 has. I was just saying that Andrew's statement that HL7 has failed is not totally correct; Thomas, Rather than arguing whether or not HL7 failed completely or partially, I think it is much more useful to discuss what lessons were learned. The fact that we may have learned different lessons has serious implications regarding our plans for OpenEHR and OIO. If I understand you correctly, you learned that reducing the reliance on translators is the key to success - and you hope to achieve that through a robust archetype authoring and standardization infrastructure. For me, I learned that developing a robust infrastructure for the production and re-use of translators is essential - since re-use of OIO forms is already a no-brainer. and regardless of the shortcomings (of which I can be as critical as anyone else), there are quite a lot of implementations, and there is a measure of success. It's been a step on the path, and a lot of things were learned. Is the new HL7 going to offer a translation infrastructure? Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
Lessons from HL7, was Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
On Sun, 28 Dec 2003, Horst Herb wrote: ... A lot has been learned, yes. But Andrew's statement - if we only look at what is actually available AND in use today - is correct: HL7 has been en exteremly expensive failure so far. A failure for more than a decade, that is. Horst, The questions are : 1) How will the new HL7 differ from the old HL7? 2) How will OpenEHR and OIO be different from the old and new HL7? ... - but in one aspect they haven't learned from their past errors, and I consider this non-learning a gloomy sign: that is, they don't publish their work freely. I suspect the new HL7 does not consider non-free to be the cause of previous HL7 failure(s). Based on the focus of their new work, it appears they must have concluded that their failure(s) came from an insufficiently comprehensive reference model. :-) ... Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
At 03:36 AM 12/28/2003, Andrew Ho wrote: On Sat, 27 Dec 2003, David Forslund wrote: How do I use OIO forms in a non-OIO application? Dave, You can't. If an application uses OIO forms, then it is an OIO application. :-) In other words, I don't want to have to run Zope to use and manage forms, and I don't want to rely on having to get to a remote OIO server to get a form, since I might be blocked by my firewall (as in the case of the entire VA). Try LiveOIO, the Knoppix-based boot disk that runs and installs OIO. What is the platform and language independent description of an OIO form? form item name description item_number prompt itemtype /item itemtype name description action choice code /itemtype /form Couldn't that be an OpenEHR archetype or an XML schema, or an HL7 CDA? Yes, that's the idea. Then why do I have to talk to an OIO server to use OIO forms? Can you take an HL7 CDA and map it automatically to OIO? In this case OIO might be used only has a way to author an archetype, OIO can be a web-based tool for authoring OpenEHR archetypes / OIO forms and also render/collect data via these archetypes(+templates) and forms. But then how do you incorporate HL7 CDA or an XML Schema? For example, if OpenEHR has an archetype that is agreed to be the right representation of some medical data, how do you incorporate that into an OIO form automatically? although there needs to be a place which maintains the official structure of a form, such as HL7 or some other body. Maybe - or end-users can simply upload forms into the OIO Library to be index and shared. This is totally inadequate and no way to manage a standard. Can you send me an example OIO form that I could simply use in my JSP web application? form item nameGender/name descriptionself-reported gender/description item_number10/item_number promptGender?/prompt itemtypegenders/itemtype /item itemtype namegenders/name descriptionphenotype gender/description actionpickone/action choicefemale,male,unknown/choice code2,1,0/code /itemtype /form What is the xml schema or dtd behind this? What is the meaning of terms like pickone? Do you have those defined?What is the meaning of item_number I use expressions like this in our application, too, but I don't consider them portable or useful to others without mapping them to some controlled vocabulary. What is the controlled vocabulary behind OIO? Also, how do I automatically get one of these forms from your server that I could use automatically? Without at least that, OIO is just an isolated application like most of the rest that we all have been developing. Dave Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
I agree with you wholeheartedly and have talked to Ed Hammond about this many times. Unfortunately, this also is the pattern of other standards bodies including all ANSI standards and ISO standards, as I understand. Dave At 12:08 AM 12/28/2003, Horst Herb wrote: On Sun, 28 Dec 2003 13:12, Thomas Beale wrote: exactly - this is the problem of N^2 translation that HL7v2 has. I was just saying that Andrew's statement that HL7 has failed is not totally correct; and regardless of the shortcomings (of which I can be as critical as anyone else), there are quite a lot of implementations, and there is a measure of success. It's been a step on the path, and a lot of things were learned. A lot has been learned, yes. But Andrew's statement - if we only look at what is actually available AND in use today - is correct: HL7 has been en exteremly expensive failure so far. A failure for more than a decade, that is. Current development looks promising and I wish them wholehearted success - but in one aspect they haven't learned from their past errors, and I consider this non-learning a gloomy sign: that is, they don't publish their work freely. You have to become a member to access their standards. It does not matter that membership is cheap - even a cent a year would not be acceptable fpr the very reason that a standard cannot be a practical and ubiquitously accepted standard (such as POP3, HTTP, HTML) unless the specifications are freely accessible to anybody. Unless they start understanding this crucial issue, I reckon they are doomed. No matter how much more money governments throw after them. The world in general is not very fond of such closed gentlemen's clubs, and end user tolerance for such behaviour is close to zero nowadays. Horst -- On two occasions I have been asked [by members of Parliament!], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. -- Charles Babbage
HL7...good idea poor outcome...Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
I wholeheartedly agree with Horst's assessment.Ten years ago I was part of the team at DEC that was bringing HealthView to market (DEC's HL7 based integration engine)...at one point in fact it was suggested that it be given it away to stimulate the systems integration business. DEC never did get the synergy right between the software, hardware and services businesses...but I digress. HL7 solved and perpetuated the problem it was meant to address. While it enabled the ability to integrate various applications through a single hub which is far better than the brittle point to point approach. It also allowed vendors to create the impression they were standards compliant by being able to say the were HL7 compliant...but each vendor often implemented their own interpretation of the standard. So as Horst pointed out a new industry was born...the integration engine business. I stopped paying attention to this stuff about five years ago... but it struck me that, from what I know, that many of the same interfaces have been coded over and over again...what would have happened if there was a public pool of interfaces for each of these hubslast I remember one had to buy them. Lastly, the HL7 / integration engine solution has also permitted software applications to remain monolithic and not break down into the more granular sized components that have been described in previous posts by Nadalal and others. In summary IMHO HL7 and other standards need to be developed and disseminated in free public forums or you get what we have had for the last ten years. The fact that integration is still an issue is clear indication of failure...money aside, I am sure if one quantified the human opportunity cost of the approach taken so far even politicians would understand what to do. Joseph On Sun, 2003-12-28 at 02:08, Horst Herb wrote: A lot has been learned, yes. But Andrew's statement - if we only look at what is actually available AND in use today - is correct: HL7 has been en exteremly expensive failure so far. A failure for more than a decade, that is. Current development looks promising and I wish them wholehearted success - but in one aspect they haven't learned from their past errors, and I consider this non-learning a gloomy sign: that is, they don't publish their work freely. You have to become a member to access their standards. It does not matter that membership is cheap - even a cent a year would not be acceptable fpr the very reason that a standard cannot be a practical and ubiquitously accepted standard (such as POP3, HTTP, HTML) unless the specifications are freely accessible to anybody. Unless they start understanding this crucial issue, I reckon they are doomed. No matter how much more money governments throw after them. The world in general is not very fond of such closed gentlemen's clubs, and end user tolerance for such behaviour is close to zero nowadays. Horst
Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
On Sun, 2003-12-28 at 11:47, Thomas Beale wrote: well, actually, even though HL7v2 had a mania of translators all over the place, and at great cost, it did succeed quite well. Where it succeeded best (to my knowledge) was in environments where translators were eliminated; i.e in New Zealand, where everyone uses exactly the same HL7 software, and to a lesser extent in Australia, where HL7v2 messages are standardised for he whole country. Um, every hospital installation of HL7 in Australia of which I am aware relies completely on the presence of an HL7 translation facility such as STC DataGate/eGate (see http://www.stc.com/products/ICAN_productsEgate.asp ) for its success. And on a small army of software engineers, steeped in arcane HL7 knowledge, who look after the care and feeding of the HL7 translation facility... -- Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0 signature.asc Description: This is a digitally signed message part
Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
Horst Herb wrote: On Sun, 28 Dec 2003 11:47, Thomas Beale wrote: same HL7 software, and to a lesser extent in Australia, where HL7v2 messages are standardised for he whole country. Thomas, now you have entered the realm of fantasy. I don't think so - I'm just saying that there are 70 or so standardised HL7 messages in Australia. The details are easy enough to get hold of. WHERE please are HL7v2 messages standardised for the whole country in any single real world example (i.e. actually used software) ? Please, WHERE? I didn't say they were in Australia; they are to some extent in NZ, to my knowledge. I know of not a single example, and I should know. Neither as a privately practising family doctor (G.P.) nor as a hospital doctor (VMO) I get a single message in HL7, not even the two largest pathology or radiology providers in our area use them. I didn't say anything about anyone usng them ni Australia; they are used in some places, but the previous PIT message 'standard' still prevails in a lot of areas. One of the minor path providers can send me pathology results as HL7 messages, but both software packages I use can't understand that particular HL7 dialect. exactly - this is the problem of N^2 translation that HL7v2 has. I was just saying that Andrew's statement that HL7 has failed is not totally correct; and regardless of the shortcomings (of which I can be as critical as anyone else), there are quite a lot of implementations, and there is a measure of success. It's been a step on the path, and a lot of things were learned. - thomas
Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
Tim Churches wrote: On Sun, 2003-12-28 at 11:47, Thomas Beale wrote: well, actually, even though HL7v2 had a mania of translators all over the place, and at great cost, it did succeed quite well. Where it succeeded best (to my knowledge) was in environments where translators were eliminated; i.e in New Zealand, where everyone uses exactly the same HL7 software, and to a lesser extent in Australia, where HL7v2 messages are standardised for he whole country. Um, every hospital installation of HL7 in Australia of which I am aware relies completely on the presence of an HL7 translation facility such as STC DataGate/eGate (see http://www.stc.com/products/ICAN_productsEgate.asp ) for its success. And on a small army of software engineers, steeped in arcane HL7 knowledge, who look after the care and feeding of the HL7 translation facility... that's not what I meant by translator - the main purpose of most HL7 interfaceware is to convert some other format to/from HL7 ( that's what HL7 messaging is about, of course ); what I was talking about was the translators needed to make different varieties of HL7 software talk to each other - i.e. software that supposedly is already talking HL7 messages. This is the basis of Wes Rishel's quote that once you have seen one HL7 implementation you've seen ...one HL7 implementation. The need for the former kind of data translation - legacy data to/from a target format - never goes away; the only question is whether you go for the ad hoc point to point approach (N^2 cost; or worse, since it's unplanned - often the same A-B transformations are solved more than once in different places or comapnies) or point - common standard approach (N*1 cost). Also, when I used the word success, I meant in terms of what a judge of the overall health system would conclude, not what a vendor company would define as success; as we all know, vendors thrive on non-interoperability and translation of data. But in terms of running a health computing infrastructure for a company, it's a vast waste of money. - thomas -- .. CTO Ocean Informatics - http://www.OceanInformatics.biz openEHR - http://www.openEHR.org Archetypes - http://www.oceaninformatics.biz/adl.html Community Informatics - http://www.deepthought.com.au/ci/rii/Output/mainTOC.html ..
Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
On Sun, 2003-12-28 at 13:28, Thomas Beale wrote: Tim Churches wrote: On Sun, 2003-12-28 at 11:47, Thomas Beale wrote: well, actually, even though HL7v2 had a mania of translators all over the place, and at great cost, it did succeed quite well. Where it succeeded best (to my knowledge) was in environments where translators were eliminated; i.e in New Zealand, where everyone uses exactly the same HL7 software, and to a lesser extent in Australia, where HL7v2 messages are standardised for he whole country. Um, every hospital installation of HL7 in Australia of which I am aware relies completely on the presence of an HL7 translation facility such as STC DataGate/eGate (see http://www.stc.com/products/ICAN_productsEgate.asp ) for its success. And on a small army of software engineers, steeped in arcane HL7 knowledge, who look after the care and feeding of the HL7 translation facility... that's not what I meant by translator - the main purpose of most HL7 interfaceware is to convert some other format to/from HL7 ( that's what HL7 messaging is about, of course ); what I was talking about was the translators needed to make different varieties of HL7 software talk to each other - i.e. software that supposedly is already talking HL7 messages. The latter is what what I was talking about too - HL7-to-HL7 translation. Many applications speak HL7, but they need an HL7 interface engine and team of minders to allow them to talk to each other, in practice. Indeed, system architects hate point-to-point HL7 interfaces - they actively prefer everything going through an HL7 hub, with some form of translation de rigeur within the hub. This is the basis of Wes Rishel's quote that once you have seen one HL7 implementation you've seen ...one HL7 implementation. The need for the former kind of data translation - legacy data to/from a target format - never goes away; the only question is whether you go for the ad hoc point to point approach (N^2 cost; or worse, since it's unplanned - often the same A-B transformations are solved more than once in different places or comapnies) or point - common standard approach (N*1 cost). It is usually considered cheaper to undertake the translation in an HL7 hub, rather than requiring each application vendor to fix their particular HL7 implementation. Also, when I used the word success, I meant in terms of what a judge of the overall health system would conclude, not what a vendor company would define as success; as we all know, vendors thrive on non-interoperability and translation of data. But in terms of running a health computing infrastructure for a company, it's a vast waste of money. HL7 2.x, as it is actually practiced, is definitely better than having no standards at all, but it is a long way from what should be achievable, given more completely specified standards. HL7 3.x should help a lot, as might openEHR archetypes, but HL7 2.x and its associated converters are well entrenched and it will take many years to replace them with something better. That doesn't mean we shouldn't try - particularly in green field sites or domains or when embarking on new software projects. -- Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0 signature.asc Description: This is a digitally signed message part
Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
Tim Churches wrote: On Sun, 2003-12-28 at 13:28, Thomas Beale wrote: This is the basis of Wes Rishel's quote that once you have seen one HL7 implementation you've seen ...one HL7 implementation. The need for the former kind of data translation - legacy data to/from a target format - never goes away; the only question is whether you go for the ad hoc point to point approach (N^2 cost; or worse, since it's unplanned - often the same A-B transformations are solved more than once in different places or comapnies) or point - common standard approach (N*1 cost). It is usually considered cheaper to undertake the translation in an HL7 hub, rather than requiring each application vendor to fix their particular HL7 implementation. yes, of course this is a more modern approach; it's the basis of more serious HL7 architectures and products (like Oracle's Health Transaction Base for example - a big centralised message switch). Also, when I used the word success, I meant in terms of what a judge of the overall health system would conclude, not what a vendor company would define as success; as we all know, vendors thrive on non-interoperability and translation of data. But in terms of running a health computing infrastructure for a company, it's a vast waste of money. HL7 2.x, as it is actually practiced, is definitely better than having no standards at all, but it is a long way from what should be achievable, given more completely specified standards. HL7 3.x should help a lot, as might openEHR archetypes, but HL7 2.x and its associated converters are well entrenched and it will take many years to replace them with something better. That doesn't mean we shouldn't try - particularly in green field sites or domains or when embarking on new software projects. right... - thomas
Security considerations again (was Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released)
On Sun, 2003-12-28 at 13:55, Thomas Beale wrote: yes, of course this is a more modern approach; it's the basis of more serious HL7 architectures and products (like Oracle's Health Transaction Base for example - a big centralised message switch). Of course, putting everything through a single HL7 transformation hub may be more efficient than other approaches, but it also creates a large single point of failure - in particular, security failure. AFAIK, most HL7 transformation engines are designed to work with the HL7 segments in the clear - that is, not encrypted - which means that any compromise of the HL7 hub is fairly disastrous, and that the Hl7 hub administrators can, potentially, see everything that is being passed between all the applications and data repositories in the organisation. This fact doesn't seem to worry many people at all. But it worries me. Of course, the security risk posed by putting all informaion through a single hub is no worse than the risk posed by storing the EHR in a single repository which implements discretionary access control - by which I mean access control [1] which can be bypassed by an administrator or superuser. If the superuser account is compromised, the entire community which relies on that EHR is in deep excrement. But, you may say, compromise of the superuser account is impossible in a well-run system...just like the recent compromise of the FSF/GNU Savannah source code repository. [1] including access control implemented through encryption of individual records or the data storage medium which relies on a single key, rather than separate, record-level encryption keys. -- Tim C PGP/GnuPG Key 1024D/EAF993D0 available from keyservers everywhere or at http://members.optushome.com.au/tchur/pubkey.asc Key fingerprint = 8C22 BF76 33BA B3B5 1D5B EB37 7891 46A9 EAF9 93D0 signature.asc Description: This is a digitally signed message part
Re: hub, spoke, new Esperanto for healthcare, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
Horst, I agree with you completely. To think that the whole of medicine can be standardised is to set forth on a never ending, increasingly frustrating quest. There are too many areas. In a sense let us start with the end user and tell them to collect data, and let them collect data in a way which makes it easy to build communicating portals for sharing information in a flexible way. Let the programmers worry about getting them to communicate rather than trying to tell them HOW they should communicate. regards Nandalal - Original Message - From: Horst Herb [EMAIL PROTECTED] Date: Wed, 24 Dec 2003 14:14:43 +1100 To: [EMAIL PROTECTED] Subject: Re: hub, spoke, new Esperanto for healthcare, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released On Wed, 24 Dec 2003 12:32, Andrew Ho wrote: 3) My proposal is to build hubs from the bottom-up - based on OIO forms that are in-use. Analagous to building a dictionary - opposite from building an universal language. Let's learn something from the failure of Esperanto, A MAJOR point, and I see this failure happening all over again and again, be it in the domain of coding (where countless professionals have been mucking around for decades in the quest for the ultimate coding system instead of settling for a thesaurus like growing dictionary of terms) or in the domain of health record architectures I'd wish we would settle for small independent modules all communicating via *simple* protocols (like XML-RPC via HTTPS or Jabber), using self-growing terminology dictionaries. I don't believe we need a monolithic architecture. All we need is well defined APIs to extract and submit data. I don't believe these APIs need to be consistent/synchronized/monolithic: - there is no reason why demographic information should be dealt with in the same way as for example vaccination records or a cardiovascular examination or drug interactions. If our systems get too complicated, we will never get there. With all due respect, the ADL of OpenEHR looks to me like a further complication rather than simplification for example - yet another mini language where I believe that using existent versatile markups (like YAML) could have the achieved the same goal with less steep learning curve and the benefit of human readability. Horst -- __ Check out the latest SMS services @ http://www.linuxmail.org This allows you to send and receive SMS through your mailbox. Powered by Outblaze
Re: hub, spoke, new Esperanto for healthcare, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
On Wed, 24 Dec 2003 14:59, Thomas Beale wrote: I just had a look - it's cute! However, it only does the dADL part of ADL, not the cADL part - there is no constraint semantics that I saw Think outside of the square. What is a constraint? I can exactly describe all our object-relational database structures including all constraints as well relationships with YAML. I can furthermore serialize any type of Python (Perl, Ruby ...) object with YAML. Now, if I can express archetypes as Python object (which I can of course) and I can accurately serialize that object with YAML, such an (empty) object would be the archetype, wouldn't it? YAML was not designed as a markup language, although to me it still is one. It was designed to serialize objects from any high level language, and for *messaging*. You can use YAML just as a replacement for XML - but that would be using only a fraction of it's potential. Shall I map you an example archetype in YAML? It would be easy I suppose. The power of data types like nested maps (dictionaries, hashtables) and ordered lists in combination with anchors (hyperlinks, relationships) allows you to express any type of constraint you can come up with. At first, you might think this is not so, it is overly simplifying. But then try to find a concrete example you cannot express in it, Horst
Re: hub, spoke, new Esperanto for healthcare, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
Horst Herb wrote: If our systems get too complicated, we will never get there. With all due respect, the ADL of OpenEHR looks to me like a further complication rather than simplification for example - yet another mini language where I believe that using existent versatile markups (like YAML) could have the achieved the same goal with less steep learning curve and the benefit of human readability. I just had a look - it's cute! However, it only does the dADL part of ADL, not the cADL part - there is no constraint semantics that I saw (but I promise to read the entire spec soon). dADL has about 1/4 of the syntax of YAML, so I wouldn't say it's terribly complex. Regardless, I am 90% sure that the dADL parts of an ADL archetype could be saved in YAML - if this seems a useful thing to do, we can write a YAML serialiser class, leaving the cADL part of the archetype in the middle intact, or perhaps with YAML-ised leaf nodes or similar. Another language we just found out about is HUTN - human usable textual notation. I actually still think we did a nice job on dADL - have a look at the 'description' and 'ontology' sections of http://www.oceaninformatics.biz/adl/repository/archetypes/ehr/entry/openehr-entry.apgar_result.draft.html. I wish XML had been done like this, to speak the truth... The 'definition' part is in cADL. - thomas
Re: OpenEHR vs. OIO semantics infrastructure, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
On Wed, 24 Dec 2003, Thomas Beale wrote: ... 1) Are archetypes versioned? How does OpenEHR support old data when achetype is changed? yes, they are versioned. There is a formal definition of the various flavours of changes to archetypes you can make - here is a rough version: - versions - fix an error in an existing archetype; this implies the data created via a previous versions is slightly wrong, and a new version always have to suply a conversion algorithm to deal with it. This is how you manage addition, changes, and deletions of attributes, correct? Can OpenEHR Templates, for example, continue to use the older version? Meaning, can multiple archetype versions co-exist at a given point in time? - specialisations - further specialise an existing archetype; only narrower constraints are allowed, guaranteeing that the parent archetype can deal with data created by the new specialised version Do you mean the addition of an attribute? With specialization, the parent archetype is retained, correct? - revisions - make changes which do not have any effect on existing data, e.g. add a new language translation of all the terms ok, but adding an attribute falls under specialization, not revision? ... the workflow to do with a PAP or vaccication recall is qualitatively different from the workflow to do with discharge referral and other events where the patient gets sent around the health system to other providers (and usually back as well). How so? I think they can be all be modeled using the same workflows metamodel. ... When I say that archetypes are globally defined, I mean that they are a priori designed as globally, or widely (maybe nationally, or across an entire specialty or disease category) usable, Same as OIO forms. and carry a conceptual definition that can be widely agreed to, Same as OIO forms. even though the concrete screen and data realisations in particular systems will be quite different. Same as OIO forms. What if you use different archetypes across these exams to represent blood pressure? ... If two parties want to use different archetypes for Systemic arterial blood pressure measurement but still share data, then there will clearly be some conversion /translation to do on the data - that can't be avoided. Right, that's what I tried to convey. ... A few _classic semantic representation problems_ come to mind: 1) What if I add 4th sound and another end-user independently also adds 4th sound - and we describe 4th sound differently? if they both map it to a relevant UMLS, snomed or Loinc term - they will more or less be obliged to choose the same term from these terminologies. Does OpenEHR require the use of terms the come from one of those terminologies? 2) What if I add 4th sound and another end-user independently adds extra sound to describe the same observation? It depends on whether you are talking about independent modifiers in different countries, or two clinicians in the same provider organisation. The key thing to remember is that the lifecycle of an archetype is not simply - modify and start using in the production system - there has to be plannnig, review, approval before it can be injected into the system; Why not shorten the cycle and just inject it into the system. Then, later build translators if they are needed? ... *With flexibility to create new terms (=OpenEHR archetypes/OIO forms) comes need for translation between terms.* Do you disagree? do you mean terms as in Snomed terms or the like? Kind of, I mean the creation of OpenEHR archetypes or OIO forms is basically creation of terms. A form-to-form translator is equivalent to defining relationships between terms. ... not so they can then go and invent unrelated ones to do the same job. Perhaps this is a fundamental difference between OpenEHR and OIO: I am of the opinion that end-users *can* and *must be allowed to* go and invent whatever forms/archetypes they wish even if you or any so-called experts believe we already have forms that do exactly the same job. This freedom of expression is a core aspect of OIO. well, I'd say it is a core aspect of a pluralist society. OpenEHR works within such a framework, its just that it is trying to find ways to make collaboration easier and minimse replication of work. How does OpenEHR make collaboration easier and minimize replication of work? OpenEHR is certainly not going to stop anyone from using all the software and creating an entire mountain of unrelated incompatible archetypes to use in their institution. Good luck to them I say;-). I think we can and should do more than wishing them good luck! This is because that's how people work - we know that, there is no doubt humans will build a tower of Babel yet again. :-) We need to fit the tool to the people and not the other way around. Thus, I think *supporting interchange* of data between different OpenEHR archetypes and OIO
Re: OpenEHR implementation, Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
On Wed, 24 Dec 2003, Thomas Beale wrote: ... I don't think so - they're a normal commercial enterprise; as far as I know they aren't going to do any OS yet, although they do know what it is. See http://www.systematic.dk/uk/welcome. They created something like an archetype system independently of our work and then read about openEHR 2 years into their development. Thomas, I cannot find anything except a very brief overview at http://www.systematic.dk/UK/Products/Columna+-+EPR/Columna+Open+Architecture/ ... You mean it is not going to be a full system that we can use to collect and manage data? no, not tomorrow, I don't quite have the spare $5m resources to do that and give it away, sorry, but it might be the following month;-). We can always implement a full OpenEHR via OIO. I won't charge you $5m and it might even be ready by the following month. :-) (And I will even help you give it away.) Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
Re: hub, spoke, new Esperanto for healthcare, was Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
On Wed, 24 Dec 2003, Horst Herb wrote: On Wed, 24 Dec 2003 12:32, Andrew Ho wrote: 3) My proposal is to build hubs from the bottom-up - based on OIO forms that are in-use. Analagous to building a dictionary - opposite from building an universal language. Let's learn something from the failure of Esperanto, A MAJOR point, and I see this failure happening all over again and again, be it in the domain of coding (where countless professionals have been mucking around for decades in the quest for the ultimate coding system instead of settling for a thesaurus like growing dictionary of terms) or in the domain of health record architectures Horst, Well said :-). I'd wish we would settle for small independent modules all communicating via *simple* protocols (like XML-RPC via HTTPS or Jabber), using self-growing terminology dictionaries. DrugRef.Org, FreeB, and ZSVG_Graph have already started this process. We don't need to settle anything - just keep building these modules. If they are easy to connect to, many systems will connect to them. I don't believe we need a monolithic architecture. All we need is well defined APIs to extract and submit data. Again, I am opposed to wasting time discussing what is or is not a well-defined API. Put forth a proposal via OpenHealth if you like, build it, and maybe your colleagues will eventually try it and give feedback. (Or just use it quietly). By the way, I have been able to communicate with DrugRef.Org via XML-RPC in Zope without issue. Great work! Look for it in a future release of OIO :-). ... Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
Seeing we're on the topic, I will note that Horst's statement of the
requirement (to be able to get a string of BPs regardless of in what
context captured) is key to managing EHR data, and if this kind of thing
cannot be done in general, systems will be quite inflexible. In an
openEHR system, BPs are captured as Observations, which are a subtype of
Entry. Entries always consist of objects of the same set of types
(Entry, History, List, Cluster, Element, and a few others - see the
upp-case names in the example below) are of the same form regardless of
how captured; Observations representing BP (as opposed to heart rate,
blood sugar or something else) always follow the same general model,
described by the archetype for BP measurement, which I have reproduced
below - mainly to show that there is quite a bit of complexity in
properly recording a BP. And yet - this still can be treated as quite
simple data in the EHR, and it can be queried in the same way,
regardless of whether it was part of a neonatal exam, general exam, or
whatever else.
You might think that this model of BP is too complicated; however it
conforms to a general model of scientific observation, and we can write
software which deals with all Observations mostly in the same generic
way, with different processing just for different details.
The path set for any such archetype can be extracted by a tool, and are
used for querying in any language.
- thomas beale
Horst Herb wrote:
On Mon, 22 Dec 2003 16:58, Andrew Ho wrote:
Maybe something like this:
Translation_table=
form1 {cardiovascular}
form_1_item {blood pressure}
form_1_item_value {any}
form2 {diabetes}
form_2_item {blood pressure}
form_2_item_value {any}
transform_function {=}
archetype
openehr-ehr-observation.bp_measurement.draft
concept
[at]-- blood
pressure measurement
description
author = Sam Heard [EMAIL PROTECTED]
submission =
organisation = openEHR Foundation
date = 2003-06-10
version = version
status = draft
revision = 1.0
description(en) =
purpose = Describe systemic blood pressure measurement
result and protocol
use =
misuse =
adl_version =0.9
rights =
definition
OBSERVATION[at0001] matches { -- blood
pressure measurement
name matches { -- any synonym of BP
CODED_TEXT matches {
definition matches {
COORDINATED_TERM matches {[ac0001]}
}
}
}
data matches {
HISTORY[at9001] matches {
-- history
events cardinality matches {1..*} matches {
EVENT[at9002] occurrences matches {1..1} matches
{-- baseline
name matches {
CODED_TEXT matches {
definition matches {
COORDINATED_TERM matches {[ac0002]}
}
}
}
data matches {
LIST_S[at1000] matches {
-- systemic arterial BP
count matches {2..*}
ordered matches {True}
items cardinality matches {0..*} matches
{
ELEMENT[at1100] matches {
-- systolic BP
name matches {--
any synonym of 'systolic'
CODED_TEXT matches {
definition matches {
COORDINATED_TERM
matches {[ac0002]}
}
}
}
value matches {
QUANTITY matches {
magnitude matches {0..1000}
property matches
{pressure}
units matches {mm[Hg]}
}
}
}
ELEMENT[at1200] matches {
-- diastolic BP
name matches {--
any synonym of 'diastolic'
CODED_TEXT matches {
definition matches {
Re: form-to-form translator, was Re: Solving the data type problem, was: ODB vs. RDMBS was: OIO-0.9.1 released
On Mon, 22 Dec 2003, Thomas Beale wrote: ... In an openEHR system, BPs are captured as Observations, which are a ... described by the archetype for BP measurement, which I have reproduced below Thomas, As we previously discussed in February 2003: http://www.mail-archive.com/[EMAIL PROTECTED]/msg07983.html like OIO, OpenEHR also allows ad hoc definition of new archetypes. Therefore, I believe OpenEHR will still require archetype-to-archetype translators - despite the much more complex structure for describing archetypes (compared to OIO forms). And yet - this still can be treated as quite simple data in the EHR, and it can be queried in the same way, regardless of whether it was part of a neonatal exam, general exam, or whatever else. This is the same as saying if you use the _same OIO form_ to record a neotatal exam, general exam, etc, your reporting application will be able to understand the semantic content without an additional translation step. If you use the same archetype across all these exams, that is. What if you use different archetypes across these exams to represent blood pressure? Now, maybe OpenEHR says no, end-users cannot be allowed to use the wrong archetype to represent the same/similar/related semantic content. Well, then how do you propose to detect/enforce/prevent that? (I don't think you can without entirely eliminating ad hoc archetype authorship.) So, in the end, the more complex archetype description language developed by OpenEHR does not eliminate the need for archetype-to-archetype translators, which is what I explained on Feb 10, 2003 during a discussion with Helma van der Linden: http://www.mail-archive.com/[EMAIL PROTECTED]/msg07879.html Consequently, maybe a minimalistic metamodel for forms (=archetypes) + a robust translation facility will be adequate (and much simpler). That's what we hope to find out via OIO's new translator module (thanks to Horst's help, it should become part of OIO-1.0.8 to be released in the next few weeks.) Best regards, Andrew --- Andrew P. Ho, M.D. OIO: Open Infrastructure for Outcomes www.TxOutcome.Org
