Tim Cook wrote: > Hi Adam, > > On Fri, 2008-04-18 at 11:55 +0100, Adam Flinton wrote: > >> >> Stepping outside of well supported standards increases maintenance >> requirements much much more. >> >> > > Well, I am not certain I would say much much more but in any case there > are reasons why new standards are developed. > > Oh indeed however there are some givens wrt stds etc:
A) Binary stds (esp "on the wire") stds have died off (CORBA, COM etc) & formatted text has taken off as a result of the plethora of langauges & uses. I used to be a big OpenDoc/SOM person & then I used to like RMI etc but....test messaging is a more "survivable" approach when people look at systems with long shelf lives (which is esp the case in terms of things like the CFH program). Like Python.....OK this will work with it....Perl? OK......C++? OK....etc.etc. Being able to read a text file/stream is just about the lowest common denominator wrt inter-systems comms. B) wrt XML the std mark up of an element <> </> etc & attributes as basically properties/ini format of x="y" is so std now (esp wrt the prevalence of HTML) that I can not see much shifting that. Wrt actual low level designs etc within that sphere (W3C Schema vs Relax or XSLTv1 vs V2 etc) & then the higher level (e.g. HL7 Mif or XMI or SVG etc) will be subject to change & the strady growth in new standards. The recent ODF/OOXML fight is an example of this. >> Heck why not write your ADL handling etc in PICK ? >> You might find it hard to get Dell et all to support Pick on your choice >> of hardware so why not try & build your own hardware with Pick optimised >> chips while you're at it? >> >> > > I assume you meant to surround this with sarcasm tags. > > Only just. Once you start down the "roll your own" route where do you stop? >> If you want to write your very own persistence mechanism/db I cannot but >> admire your ambition but I would caution wrt expecting others wishing to >> use it vs spending a bit more on hardware. >> >> > > This wasn't the subject. I used the SQL database use as an analogy. I > don't need to create my own (even if I could) object databases prove > themselves very useful in implementation. > > See above. >>> How this applies to healthcare is that healthcare information must >>> contain truth. That truth is fully dependent on the complete context of >>> where, when and how it was recorded. This context needs to be >>> understood in all spatial and temporal instances where this information >>> is or may need to be used. >>> > > >> An obvious response would be that Heisenberg would argue with the above. >> > > Well, I am not a quantum physicist and would not argue with him in that > domain of course. However, a lot has changed in information processing > since he passed away in 1976. I would venture to guess that he might > have made some adjustments to his uncertainty principle in the process. > > There is certainly a great deal of vagueness in healthcare information > and the ARB has had MANY discussions about handling these situations. > But I still maintain that vagueness nor uncertainty negates the expected > truth value of healthcare information. The truth of healthcare > information exists in the context of which it is collected. It may > later proved to be incorrect but if the complete context of the > information is known, it will be understood by the receiver. > > An interesting subject indeed but we are drifting off the subject to > some extent. :-) > > <G> > >> However the whole point of an object model (as opposed to an object >> implementation) is that it is implementation neutral. >> >> > > True. But the implementation must faithfully represent the semantics of > the model or it isn't an implementation. > > No argument from me. However to take the example of UML (& please note I am not a great fan of UML as it is more of a "meta-standard" (try taking a xmi/model from one "UML" tool to another....)) you can design your class diagram etc & then persist/implement that model in all sorts of ways. So long as you can faithfully re-create that model then...... e.g. A mate of mine called Bob has built this: http://umlspeed.sourceforge.net/ Which I often use for quick modelling. As an example from the above, Were there an AOM/MOF mapping then in theory you could persist an archetype out as XMI. BTW sidenote: I have looked at both a "MIF/MIF Mapping " (I like the name if not the result <G>) & an AOM MOF. Dave Carlson of the VA has done much more on the HL7 part & that will (hopefully) help towards the creation of a consistent MOF/EMF model for HL7 wrt doing our eclipse tooling. I will raise this as a different thread. >> "As part of its commitment to OHT, NHS Connecting for Health has >> contributed an XML processing engine" >> > > > I look forward to your work be proven in implementations. I think it > COULD be wonderful to use XML. > > It could indeed. >> >>> [NOTE] You will also need to address the issues that Thomas Beale just >>> presented, in the referenced thread, regarding the real world as well. >>> >>> >>> >> I have done so. >> > > I agree with your format vs. design comments there. But, your examples > lead me to believe that you are still focusing on sending messages with > limited context and have not considered implications regarding storage > and retrieval of healthcare information for decision support, public > health analysis, etc. > > oh don't go there......I have had months of fun wrt the above & do not wish to revisit that. I will say in summary that if one were to keep all info & to wish to retrieve that then it would be unworkable & that the reality is that it's a matter of working out what to keep & what to discard period irrespective of language etc. > I look forward to continued to discussions/education on your XML > progress. > > Now back to our regularly scheduled work! ;-) > > OK Adam ********************************************************************** This message may contain confidential and privileged information. If you are not the intended recipient please accept our apologies. Please do not disclose, copy or distribute information in this e-mail or take any action in reliance on its contents: to do so is strictly prohibited and may be unlawful. Please inform us that this message has gone astray before deleting it. Thank you for your co-operation. NHSmail is used daily by over 100,000 staff in the NHS. Over a million messages are sent every day by the system. To find out why more and more NHS personnel are switching to this NHS Connecting for Health system please visit www.connectingforhealth.nhs.uk/nhsmail **********************************************************************
