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
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
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: 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: 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
