[Gnumed-devel] RE: Gnumed-devel Digest, Vol 7, Issue 20

[s j tan]

-----Original Message-----


Date: Fri, 20 Jun 2003 02:19:06 +0200
From: Karsten Hilbert <address@hidden>
To: address@hidden
Subject: Re: [Gnumed-devel] RE: Gnumed-devel Digest, Vol 7, Issue 18
Message-ID: <address@hidden>
In-Reply-To: <address@hidden>
References: <address@hidden>
        <address@hidden>
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Precedence: list
Message: 7

> w.r.t. structured data, recently I had
> a dispute ( seems like every time I try to make a contribution) with
> Karsten about how exactly to link up encounters with episodes with
> entries etc...
My understanding is entirely based on that Dutch reference
summary. It's not like I made this up in a lazy minute. If we
want to deviate from the Dutch proposal I'd like to see
reasons for that. I'm very willing to change things if I'm
shown good cause for it.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


------------------------------

I was just pointing out that lazy/eager choice, and at the time , I
assumed
It was going to be eager and didn't know how it was going to be done.
You're right in thinking I had assumed it was an invented structure, so
apologies. It looked like some sort of organizing relationship, and some
models seem to allow for dynamic organizing relationships, but it's hard
to see where agreement about level of normalization is.

Here's a review of some stuff I've been looking at:
the RIM looks more Like the Fowler model I've been looking at, but it's
got a lot more attributes, and some of them look like coded attributes
which could be modeled as links or relationships, but they might have
decided to stick them on the class for performance / convenience
reasons, or to highlight they are for another function such as
mapping/interoperability rather than part of the model.
        The Fowler model and RIM seem to agree that Act/Action should be
a class, and that Observation inherits from Act. What differs is
Fowler's ideas about Protocol. For things like Proposed, Implemented,
Suspended, Cancelled actions RIM I think uses a mood code, whereas
Fowler has a multiple inheritance model so there's ProposedAction,
ImplementedAction, but Fowler goes further in letting ProposedActions be
elements in Plan which also inherits from Action. Fowler tends to keep
things fairly general, and is more concerned with relationships, as most
entities don't have attributes, whereas the RIM has a
SubstanceAdministration and a Procedure subclass for Action, the
substance Adminstration class having the usual dose frequency
attributes, but seems to put constraints on dose and frequency as set
attributes of SubstanceAdministration. Fowler doesn't go into how to
model drug administration at all, but you could argue it could be in
some sort of Plan , or some sort of ResourceAllocation (Fowler) which is
linked to an Action. Fowler has Protocol separate from Plan, so that
plans can be individualized but follow a Protocol partially ( I think).
Both Fowler and RIM have a separate Act link entity which allows
hierarchical relationships between Acts/Actions ( 1 parent, many child
actions), but RIM puts some fairly opaque (by name) attributes on the
relationship class.
Actions are link to Entities or Party/Persons through intermediate
classes both in RIM and Fowler: RIM uses Role and Participation as
intermediates between a PersonEntity and an Action , whereas Fowler uses
an Acccountability concept, with the Accountability linked to a
AccountabilityType and a PartyType , which links back to Party. I
suppose
RIM doesn't need to express Knowledge vs usage level relationships,
because 
One could store templates of a Role-Participation and copy the templates
as a kind of Knowledge level model. 

 The HL7 site has a RIM billboard pdf which shows a birdseye view of
RIM, but hides the complexity of the complex types it uses for
attributes.
  I can put a gif of an attempt at UML modeling the fowler model at 
http://users.bigpond.com/~sjtan/ehr-stuff/index.html