Hi, I find this discussion very interesting, and while I fundamentally agree that more "advanced" modelling is necessary - particularly if you want highly customisable applications - it seems like most such efforts within the health sector is focusing on patient systems. Most of my work is related to health MANAGEMENT info systems, where the primary "entities" with related attributes & processes are not people but - Health facilities (clinics, hospitals, mobiles, GP practices) or sub-sections thereof - Services (primary/secondary/tertiary, often cutting across physical facilities) - Health programmes (usually national in scope) - Ministries, NGOs, other health providers and so forth.
We're also using three generic types of data elements: routine data (weekly, monthly, annually); semi-permanent data (population mid-year estimates, services, equipment, infrastructure); and survey data (which overlaps the first two but usually also more focused on qualitative measurements). Indicators might in theory be any combination of the three that are useful for monitoring and evaluation. What makes HMIS data modelling complex is also that it is much more dependent on socio-economic, cultural, political and administrative systems (people are at least physically more or less identical everywhere). So flexibility must be high, OR the models must be based on the assumption that it will usually not be directly replicated but rather adapted to new countries/environments. Is anybody aware of any existing modelling efforts that might be relevant for our work? regards calle ----- Original Message ----- From: "Horst Herb" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, April 30, 2004 8:09 AM Subject: 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
