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