[ahhh... the beauty of having reply-to set to the list!]
Isabel Rom?n wrote:
> Hello everyone!!
>
> I have a doubt with the difference in the attribute time_validity in
> the classes ROLE and CAPABILITY. The description of both in the
> Revision 1.4.4. of the demographic model (the one I`m using) is the same:
>
> Valid time interval for this role
>
> If this is correct I think that one of the two attributes could be
> deleted because it referes to the same concept. I think that the ones
> in CAPABILITY class could be deleted...
there is a typo in the model here. There are intended to be two
attributes. The time_validity of in the CAPABILITY class relates to the
credentials. The time_validity in the ROLE class relates to the role
played by an actor.
Let's say a Person (an Actor) is a General Practitioner (GP; = "family
doctor" in some countries). They have a Capability of "Medical Doctor",
or some equivalent, with academic credentials of some certificate,
diploma or other recognised proof e.g. in Australia it is the "MBBS,
which means bachelor of medicine, bachelor of surgery". The
time_validity of this is from the date they got it, and is probably
open-ended. As a GP, they must have trained as a GP - they will also
have some kind of accreditation certificate from the college or GPs,
family practitioners or whatever - to show that they have done GP
training; the time_interval for this might be open-ended, but it might
also be limited - e.g. if it is required that GPs do some kind of update
training every 10 years. They may also have to have other "capabilities"
such as insurance etc, each of which will probably be limited in time.
In most countries they will have a provider number, which will have its
own certificate from the government, allowing them to practice medicine
and charge for it, and recoup money from medicare, etc etc. This is of
course very variable across countries.
Now, this doctor with these various capabilities would be able to
undertake various roles in various organisations. She might operate as a
GP within a certain clinic; so her role might be "General Practitioner"
or "consultant" - whatever they call her. The time_validity of this role
will probably be limited - it may be a year-long contract for example.
You can see in the later examples in the document where people take
roles like "head cardiac surgeon" and so on.
Discussion
Now, this model isn't completely ideal, although it follows previous
work in this area. The problem is that it doesn't quite make clear the
concept of "capacity", as in "role which an actor is capable of
playing", and "post", which is a "role/position" available in some
organisation or group. A person can clearly have the capacity of being a
GP, with all the relevant, up-to-date capabilities, such as descibed
above, even if they are not currently employed in any team or
organisation. A "post" on the other hand is a position which requires
one or more capacities and which is usually governed by a time-limited
contract; think of it like a socket that a person with the right
capacities could fill.
There are commonly unfilled posts, as well as actors not currently
employed in one or more of their capacities. Unfilled posts might have a
time limit on them; a capacity/possible role is only time-limited by the
specific capabilities. But when a person playing a role (=acting in a 1
or more capacities) takes a post, the contract is usually time-limited.
In the current demographic model, posts are represented by
PARTY_RELATIONSHIPs; the time-validity on a filled post (= legth of
contract) is expressed by the time_validity of the PARTY_RELATIONSHIP
object. Currently, theattributes source and target of PARTY_RELATIONSHIP
are both 1..1, meaning that the only kind of post is one that is filled.
This could probably be relaxed to target = 0..1, allowing unfilled posts
to be represented properly, but I don't know if we are really interested
in doing this.
My original feeling was that a clinical demographics service is there to
represent current relationships only - who is working where and in what
capacity, so as to support audit-trailing in the EHR. Does a clinical
demographics service want to model the entire set of teams and job
openings for an organisation? For pure EHR use, probably not. But this
information most likely needs to be represented somewhere, and there is
a contrary argument that the openEHR demographics service is as good a
place as any - especially since you get the benefits of archetyping.
Future Possibilities
Where we go with this model depends on its use by the community - I
believe we need feedback from users. In my view, it is clearer than the
Fowler or HL7 RIM work in this area, and more flexible, and it can be
used to represent capacity and post. But it could also be clarified to
make this easier. It might just need better documentation on our part,
or it might need changes.
Improvements to the documentation of the current model could show:
- how to use a ROLE and a PARTY_RELATIONSHIP to represent a
post/position. The ROLE in this case would act as a post definition; the
PARTY_RELATIONSHIP's meaning would be things like "post", "permanent
position", "temporary post" and so on.
- how to use a ROLE to represent a capability which does not change due
to employment status
- how a person with a capacity (= playing a role) fills a post. The
objects required for this would be
ORGANISATION----PARTY_REL(type of post)----ROLE(post
definition)----ROLE(capacity)----PERSON
This is one more ROLE than is presently used for this situation. Now,
critics might call this approach somewhat excessive. But remember - it
is all governed by archetypes, and clear archetypes can be defined to do
this.
Possible improvements to the model might include:
- adding a new class representing the concept of "post" or "position";
this could be modelled as a set of responsibilities, plus a list of
required capacities.
- possibly renaming ROLE as CAPACITY? Not sure that this is a good thing
- people are used to thinking of a PERSON playing a ROLE. Problem is
they might mean "being a GP" (really a capacity) or "currently working
as a GP at clinic X" (really filling a post).
- the scenario described above would then be represented by the object
structure:
ORGANISATION----PARTY_REL(type of post)----POST(post
definition)----CAPACITY(capacity)----PERSON
The meaning of the above would be that: PERSON x with one or more
CAPACITYs is currently filling a POST at ORGANISATION y, under
conditions described in the PARTY_REL.
- thomas beale
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org
