Re: HXP
On Fri, 30 Apr 2004 15:43, Andrew Ho wrote: Just as an example, how would OpenEHR model telephone1 and telephone2? The reason we and many others have gone to the trouble of doing more than simple-minded modelling is to get out of the numerous problems that such modelling brings with it. There are always design trade-offs. Let's investigate this simple example a bit more so we can better understand the benefits and risks of using simple-minded vs. impractical modelling approaches. :-) For this concrete simple example: 1.) reality is that people have none to many phone numbers. I, for example, have 6 that are relevant to my person. 2.) Such telephone numbers usually require an attribute to tell which number to use for what purpose. Hence, the ideal mapping to a XML-RPC compatible data type would be a dictionary list (list of key:value pairs) like (simplified for readability) phone location = home 1234567 /location location = work 2345678 /location location = mobile private 1234567 /location location = mobile work 1234567 /location location = fax 1234567 /location /phone A remote procedure call would then be provided to retrieve all phone numbers belonging to an individual. Due to the substantial call overhead and inherent redundancy of XML-RPC, you would always try to anticipate further queries in your return values, hence you would not just query for fax number but simply for all phone numbers and parse the returned structure on the client side. Horst
Re: HXP
Andrew Ho wrote: On Fri, 30 Apr 2004, Thomas Beale wrote: ... Telephone1/telephone2 and similar ideas are really not good modelling, and will almost instantly break, as well as having limited use from the outset in widely different cultures/environments. Thomas, Just as an example, how would OpenEHR model telephone1 and telephone2? Firstly, the model is at http://www.openehr.org/Doc_html/Reference/Information/demographic.htm (this link will probably break in 24 hr due to website changeover..). You will see that the object structure is PARTY contacts [0..*] CONTACT addresses [0..*] ADDRESS Now consider what it is you really want record: it is things like: - business hours contacts, e.g. might be a phone, plus email - out of business hours, might be another phone, plus a mobile, plus a postal address - emergency number, anytime - physical home address - etc Each contact has some purpose and valid time interval (might be repeating, as in the case of business hours); then for each contact, e.g. the second one above, there might be more than one kind of address - e..g phone, email, postal and so on. So you can probably see that recording telephone1 and telephone2 in a flat structure are not going to model any of this very normal reality of contacting people. The reason we and many others have gone to the trouble of doing more than simple-minded modelling is to get out of the numerous problems that such modelling brings with it. There are always design trade-offs. Let's investigate this simple example a bit more so we can better understand the benefits and risks of using simple-minded vs. impractical modelling approaches. :-) I agree: examine it carefully, and consider other similar deficiencies in such models, and the combinatorial effects such approaches can have. But I would also say: a lot of these problems are well known, understood and documented in IT; hopefully people here don't want to go and rediscover it all again the hard way. - thomas
Re: HXP
Please show us how you wish to do it for accessing GnuMed via hxp! It seems that this http://savannah.gnu.org/cgi-bin/viewcvs/gnumed/gnumed/gnumed/client/wxpython/gmMacro.py is what you are looking for. However, authentication issues are unresolved (we only use the interface locally) and that is what Dave was pointing out as reinventing CORBA eventually and Horst mentioned as being solvable by transporting Jabber content. Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Re: HXP
It is also solvable the easy way by 1.) disallowing plain http, requiring https 2.) via https, passing plain text authentication to retrieve a authentication token (since this is a stateless protocol) 3.) from now on, ping-pong the authentication token hash in the usual way 2+3 is exactly what we do now except for the https part which isn't really hard to add as long as the xml-rpc libs support (I think the Python implementation does). Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Re: HXP
There are always design trade-offs. Let's investigate this simple example a bit more so we can better understand the benefits and risks of using simple-minded vs. impractical modelling approaches. :-) Whatever. If using a plain old relational database system, one can hold contact information in a table separate from the patient's name in fact, given that one human entitymay carry different names, sexes, dates of birth [1] from time to time, there is some merit in using one table to hold identity, the rest or majority of the fields being linked from other tables, whose key is the identity from the first one. This applies to addresses, telephone and other contact numbers and so on. I infer that the design of the central registry of the NHS is defficient in this respect either from deliberate choice or oversight, since the NHS number may not change and people whose expressed sex changes get a new NHS number and medical record. The fields I'd look for in contact details include a TypeOf field saying if it is a voice number, data, fax, etc, and a rather free form field giving instructions on what purposes it might be used for and when to choose it - for human interpretation, and commonly left unpopulated. [1] as some form of error, or of deliberate obfuscation, and yet one would wish to bring all the records together under some circumstances. -- Adrian Midgley (Linux desktop) GP, Exeter http://www.defoam.net/
Re: HXP
At 06:14 AM 4/30/2004, Adrian Midgley wrote: in fact, given that one human entitymay carry different names, sexes, dates of birth [1] from time to time, there is some merit in using one table to hold identity, the rest or majority of the fields being linked from other tables, whose key is the identity from the first one. This applies to addresses, telephone and other contact numbers and so on. This is precisely the data approach used in the OMG PIDS specification. It doesn't mean that it has to be stored in that form. I think it is a bad idea to link the data interchange format to the data storage format. You might choose to do that, but there is no reason one has to. Dave
Re: HXP
I've attached an XML schema for the PIDS data model that we use. It is completely consistent with the OMG PIDS specification.This entire issue of flexible dynamic traits vs rigidly defined traits was discussed in great detail during the development of this RFP. As a result we agree very well with the Archetype models proposed by openEHR. Dave At 11:31 PM 4/29/2004, Thomas Beale wrote: Horst Herb wrote: Initially I was thrilled by HXP. Pretty much the suggestion I was pushing locally for the past two years, and a delight to see somebody actually organizing it. A simple and straightforward solution, very easy to implement, close to zero initial barriers, but immensely expandable. However, after reading a few details, I was dismayed: Why, oh why, perpetuate the deficiencies of flat table data storage into the 21st century??? While XML-RPC caters for complex dynamic data types such as maps (dictionaries) etc., how comes that we still would find telephone1 and telephone2 Breaking all rules of good database design, and that includes designs of persistent objects or access to such. I also noticed this - and had the same thoughts. There are nice models to use for demographics such as the one we have proposed in openEHR, which is based on the ideas of Martin Fowler and others who have developed such models; (the openEHR one is proven in trial software) - it is a completely soft model of attributes (controlled by archetypes, but you don't have to use them if you don't want); else if you want a more API-flavoured model, use the Corbamed PIDS model. Telephone1/telephone2 and similar ideas are really not good modelling, and will almost instantly break, as well as having limited use from the outset in widely different cultures/environments. The reason we and many others have gone to the trouble of doing more than simple-minded modelling is to get out of the numerous problems that such modelling brings with it. - thomas beale ?xml version=1.0 encoding=UTF-8? xs:schema xmlns:xs=http://www.w3.org/2001/XMLSchema; elementFormDefault=qualified xs:element name=PIDS xs:complexType xs:sequence xs:element maxOccurs=unbounded ref=Identity/ /xs:sequence /xs:complexType /xs:element xs:element name=Value type=xs:string/ xs:element name=Trait xs:complexType xs:choice xs:element ref=Value/ xs:element maxOccurs=unbounded ref=Trait/ /xs:choice xs:attribute name=Type use=required xs:simpleType xs:restriction base=xs:token xs:enumeration value=HL7/ xs:enumeration value=PIDS/ xs:enumeration value=vCARD/ xs:enumeration value=NODE/ xs:enumeration value=S/ xs:enumeration value=B/ /xs:restriction /xs:simpleType /xs:attribute xs:attribute name=Name use=required/ /xs:complexType /xs:element xs:element name=Id type=xs:string/ xs:element name=Identity xs:complexType xs:sequence xs:element minOccurs=0 ref=Id/ xs:element maxOccurs=unbounded ref=Trait/ /xs:sequence xs:attribute name=State default=PERMANENT xs:simpleType xs:restriction base=xs:token xs:enumeration value=UNKNOWN/ xs:enumeration value=INVALID/ xs:enumeration value=TEMPORARY/ xs:enumeration value=PERMANENT/ xs:enumeration value=DEACTIVATED/ /xs:restriction /xs:simpleType /xs:attribute xs:attribute name=PreferredId/ /xs:complexType /xs:element /xs:schema
Re: HXP
Hi Dave, thanks a lot for this schema. I can sense the enormous amount of design deliberations behind it. It is a very respectable work. On Friday 30 April 2004 09:46, David Forslund wrote: I've attached an XML schema for the PIDS data model that we use. It is completely consistent with the OMG PIDS specification.This entire issue of flexible dynamic traits vs rigidly defined traits was discussed in great detail during the development of this RFP. As a result we agree very well with the Archetype models proposed by openEHR We are still waiting for your promised servers to enable us to test this schema. Also, please point us to libraries or drivers that we can use in our applications to hit your servers using the PIDS data model. By the way, the xmlrpc libraries available around make the protocol transparent to the programming language. The programmer does not even need to know how the xml formatted data being exchanged looks like. He thinks on the basis of his programming language. It will surely improve acceptance if this is to be found in your protocol. Can you please point us to similar libraries or drivers which make your protocol transparent to the programming language? We will highly appreciate it. Regards, Elpidio
OSCAR v2 beta release
Please see announcement about the release: http://freshmeat.net/projects/oscarmcmaster/?branch_id=42988release_id=159205 Many thanks to the Brazillian collaborators!! Best wishes, David David H Chan, MD, CCFP, MSc, FCFP Associate Professor Department of Family Medicine McMaster University http://oscarhome.org
Re: HXP
Hello Horst, thanks again for the very careful observation. I can remember last time when someone mentioned a HIS project on this list, you also immediately pointed out the database aspect. We highly value your expertise on this. On Thursday 29 April 2004 22:06, Horst Herb wrote: Initially I was thrilled by HXP. Pretty much the suggestion I was pushing locally for the past two years, and a delight to see somebody actually organizing it. A simple and straightforward solution, very easy to implement, close to zero initial barriers, but immensely expandable. Yes, you are right on this. May I add, this is probably the so-called large white wall However, after reading a few details, I was dismayed: Why, oh why, perpetuate the deficiencies of flat table data storage into the 21st century??? I refuse to believe that you get discouraged too easily, Horst. My high respect of you just simply preventa me from believing it. It doesn't fit your intellectual profile, so I assume that you are just joking. We want to pattern the hxp talk after common human conversation habits (of course in a subjective way). If we take english for example, we will surely wonder why we are still using it today (when was english actually invented?). While XML-RPC caters for complex dynamic data types such as maps (dictionaries) etc., how comes that we still would find telephone1 and telephone2 Breaking all rules of good database design, and that includes designs of persistent objects or access to such. Yes, this is probably the so-called that tiny spot in the middle of the large white wall. These are current proposals and as such are bound to be accepted or discarded. But I say probably because the final decision to accept or discard proposals (the proposals may come from you) will be based on the proven actual usefulness or uselessness. For this purpose we need to rigorously test procedures at least in demo applications (ideally in many applications with different design philosophies). If you remember the part on the website about proposing: nobody is allowed to discriminate other people's proposals. So making a counter-proposal does not automatically defeat the ones being countered. This protects you, me, and all of our intellectual efforts during the proposals phase. Lets say, Horst proposed something, then later on Dave countered it, Horst's proposal will not be summarily dropped. But instead the two will be given the chance to prove their proposals' usefulness (or uselessness). In this connection, it is important that Horst and Dave create demo applications that support their proposals. These demos should be accessible to the largest number of potential users possible (online demo is the best for this purpose). Allow me to summarize: a) Make a proposal in a formal way. Make a pdf document and we will publish it alongside the other proposals. b) Create a demo application supporting the usefulness of your proposal (preferably online demo) c) Instruct us how to use your demo. Anybody is allowed to do anything to market his proposals (his ideas) effectively to all of us. But hitting-below-the-belt and discrimination are mortal sins (you will burn in hell :-) ). Now to the question of how can we find the better proposal: well, when a large number of people are testing, the best practice will become obvious very easily. And note: complex and politically correct does not guarantee it to be the best on practical grounds. Let us democratize protocol developments and let the people decide. Respectfully, elpidio
Re: HXP
At 10:55 PM 4/30/2004, Elpidio Latorilla wrote: Hi Dave, thanks a lot for this schema. I can sense the enormous amount of design deliberations behind it. It is a very respectable work. Please remember that this schema is not an official part of the OMG specification, but it is what we have used so that we can have a full XML representation of the data that the OMG PIDS expects. It has some small extensions as to the type of data as the spec only handles HL7 and vCard officially, as well as a few special PID types. We have found that it works very well for a variety of application areas far beyond healthcare. Also remember that the PIDS specification lets you ask it what are the properties of any particular trait type, so that a conformant system can not only tell the client what is supported but something about what the particular traits mean. On Friday 30 April 2004 09:46, David Forslund wrote: I've attached an XML schema for the PIDS data model that we use. It is completely consistent with the OMG PIDS specification.This entire issue of flexible dynamic traits vs rigidly defined traits was discussed in great detail during the development of this RFP. As a result we agree very well with the Archetype models proposed by openEHR We are still waiting for your promised servers to enable us to test this schema. Also, please point us to libraries or drivers that we can use in our applications to hit your servers using the PIDS data model. All of the libraries and drivers to access it through CORBA are on http://OpenEMed.org, of course. I've not provided the web services/xml-rpc/rest interfaces yet. This has not yet been a high priority for me to do, since the existing interfaces provide full interoperability, high performance, security and standards based. By the way, the xmlrpc libraries available around make the protocol transparent to the programming language. The programmer does not even need to know how the xml formatted data being exchanged looks like. He thinks on the basis of his programming language. Perhaps, but I don't understand why you insist on having a username and password in the arguments. This makes the communication very awkward and not particularly useful for real secure systems that don't use passwords. In our experience the security is negotiated completely independent of the call and is enforced on the wire by the underlying protocol. I would assume such is possible with xml-rpc. The CORBA solution also means one thinks in terms of their programming language and, in fact, don't even have to think in terms of XML if they don't want to. (Many people today think of XML as a programming language). The protocol is totally transparent to the programming language in the approach of the OMG PIDS. I see all kinds of work going on trying to figure out how to tear apart an incoming message (which is also true in HXP, as far as I can tell). We haven't had to deal with how to tear apart an incoming message for many years. We have many people using CORBA who have no idea that is what they are doing. They only think of making calls to objects. EVen with XML-RPC, I have to convert from my programming language to something else to make the XML-RPC call. If I used XML-RPC, I will be wrapping it with something that takes care of this problem, too. So in one sense, there is nothing new here, just something different and with different comfort factors. It will surely improve acceptance if this is to be found in your protocol. Can you please point us to similar libraries or drivers which make your protocol transparent to the programming language? We will highly appreciate it. Check out our code base. For example we have in the src/clients/gov/lanl/Web directory classes which let web applications use our (or any OMG standard) service without having to know anything about CORBA. I will be adding additional interfaces in this package or a related one to enable the pure web remote access. Thanks, Dave Regards, Elpidio
Re: Secure Filesystems
On Fri, 2004-04-30 at 12:15, [EMAIL PROTECTED] wrote: Research on filesystems, mostly Unix and Linux, indicates a possibility that a secure filesystem can be created that can resist attempts to access it by applications and 'users' that are not properly authenticated. Furthermore, there is a possibility that 'levels of access' could be an integral component. Suggest that you examine SELinux, which is now included in Fedora Core 2. Combine the MAC (mandatory access controls) of SELinux with encrypted filesystems and you have the infrastructure you need for what you envisage. Exactly HOW to combine them requires more work, but there's your opportunity. -- 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: HXP
Hi Horst, this is a very good idea. Will you setup an online xmlrpc-via-jabber server for all of us on this list? I have used jabber before using 2-3 clients both on windows and linux, but I guess we cannot use them for our health apps, can we? So we need some libraries or drivers. Are there libraries/drivers available around? thanks in advance, elpidio On Friday 30 April 2004 00:16, Horst Herb wrote: It is also solvable the easy way by 1.) disallowing plain http, requiring https 2.) via https, passing plain text authentication to retrieve a authentication token (since this is a stateless protocol) 3.) from now on, ping-pong the authentication token hash in the usual way I prefer xml-rpc via jabber because it takes a lot more into account than just authentication and security. For example: - on demand store-and foreward when a connection breaks down temporarily or episodically - presence/absence discovery - text and even videoconferencing via the same protocol and server - and much more Horst
Re: HXP
I have some questions about jabber. Can a non-jabber client talk to a jabber server with xml-rpc? Or does one commit to the jabber protocol completely? Why not use one of the other standard messaging services? With jabber, why use xml-rpc at all? Dave At 01:15 AM 5/1/2004, Elpidio Latorilla wrote: Hi Horst, this is a very good idea. Will you setup an online xmlrpc-via-jabber server for all of us on this list? I have used jabber before using 2-3 clients both on windows and linux, but I guess we cannot use them for our health apps, can we? So we need some libraries or drivers. Are there libraries/drivers available around? thanks in advance, elpidio On Friday 30 April 2004 00:16, Horst Herb wrote: It is also solvable the easy way by 1.) disallowing plain http, requiring https 2.) via https, passing plain text authentication to retrieve a authentication token (since this is a stateless protocol) 3.) from now on, ping-pong the authentication token hash in the usual way I prefer xml-rpc via jabber because it takes a lot more into account than just authentication and security. For example: - on demand store-and foreward when a connection breaks down temporarily or episodically - presence/absence discovery - text and even videoconferencing via the same protocol and server - and much more Horst
Re: HXP
Emmm, I cant answer that Dave. But I am sure Horst will illuminate us on this. I can speculate it to be via libs or drivers. Not sure though. elpidio On Friday 30 April 2004 14:49, David Forslund wrote: I have some questions about jabber. Can a non-jabber client talk to a jabber server with xml-rpc? Or does one commit to the jabber protocol completely? Why not use one of the other standard messaging services? With jabber, why use xml-rpc at all?
