I also meant to send this to HRAC list.
-- BEGIN included message
- To: coas@cs.fiu.edu
- Subject: Re: [COAS-List] RE: HRAC submeeting team meeting July 30, 1998: minutes
- From: Wayne Wilson <wwilson@umich.edu>
- Date: Tue, 04 Aug 1998 09:44:07 -0400
- References: <002801bdbf5d$0c242100$7b4ef5cd@juggy.careflow.com>
- Sender: owner-coas@cs.fiu.edu
V. Juggy Jagannathan wrote: > > the > problem is that > given the above set of dimensions, one may construct arbitrary trees. One > can conceivably put the > patienID at the top node - given a patient info can from multiple sites, one > can put conceptCode at the > top of the tree, etc. > I have to agree with Juggy here, while one can argue that any given organization can, by policy fiat (or specific tree implementation!) mandate a particular view, my experience shows these to be fluid over time and not subject to consensus among the various communities of interest within the organization. Having said that, I also note that among certain sets of observations there will be well known, non-contentious relationships that can be represented by some sort of structure, e.g. from COAS submitters meeting in Helsinki: Blood Pressure contains two members, Systolic and Diastolic. Security policy could be applied to the Blood Pressure instead of it's components. Perhaps, what we have is a 'lumpy' flat space, with the lumps being composit resources. Where is the knowledge of compositing relationships? Once again, at Helsinki we discussed two approaches and decided that we could rule neither of them out in the COAS model. Once approach assumes a 'structure or relationship' schema server is available and the other approach does not and requires schema fragments to be emitted along with the observations in some schema language such as RDP.
-- END included message