[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