In een bericht met de datum 15-9-2006 23:15:45 West-Europa (zomertijd), schrijft randy.neall at veriquant.com:
> > Since I'm not sufficiently acquainted with all the details of either system > I could not follow each nuance of the argument. But among the things I'm > taking away from this is that HL7 involves a complex and ever-changing schema > at > the DB storage level, something that worries me. I did not hear a rebuttal of > this point from the HL7 side. > I am not a specialist on this, but I believe it is possible to have a quite simple DB schema based on HL7 v3. Difficult parts include the Entity parts (person, patient, organisation) because the entries in fields will change for some and not for other (e.g. changing addresses, phones etc. relationships between entities are handled via roles: that is not changing. participation from a role in activities are not changing. Of course there are different kinds of participation that change, but that is doable with coding then there are acts that have relationships with other acts, identifiers, moodcode and status codes, as are codes, times and where the act is an observation: there is a value. These parts of the RIM and D-MIMs have been stable for quite a while. Key of Act storage is to store the code for the act, the time, the author (via participation / role relationships), the mood (request, promise plan, carried out) and the status (activive, obsolete, competed). These things have not changed in principle. However, the D-MIMs derived from RIM have changed in those domains where development is ongoing. For some implementers it means for instance that the condition class cannot be used anymore. Instead we work with a problem list allowing activities to be associated on problem level and not on 'condition' level. Condition is changed to an observation. Part of this is because not all components of the HL7 v3 standard are ready now. Early implementers of work in progress thus will face changes that affect their developments. For the Netherlands national ICT project we include the industry in the work in progress and discuss this situation with them before starting and during development and balloting of standards. To prevent too many changes we have now the draft standard for trial use DSTU that allows a couple of years fixation of the standard, testing, finding out the problems, revising and then develop the final standard and ballot that. William Goossen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060917/968058f4/attachment.html>
