Thomas Beale schreef:
Bert Verhees wrote:
I willb e grateful if you correct me if I am wrong.
I wonder how the subject connection should look like.
The available archetype-editors do not offer demographic-archetypes, and
in the collection of available archetypes, there are also no
demographic-based archetypes .
One could think that demographic archetypes are a kind of legacy.
Does that mean that the demographic classes in the Reference Model will
go the same way?
Thanks, Thomas, for your reply!
Hi Bert,
on the contrary, demographic archetypes and demographic a archetype
editor capability will have increased development around them in 2008.
I am glad to hear, although, I heard some people wanting to have demographic information on generic base, put in to item_structures, instead of specialized classes.
I mean, In the EHR-class, there is EHR-Status, which clearly describes
that it needs a pointer to a Party_Self, which is in fact a pointer to a
Party_Ref, which is in fact a pointer to a Party-class/object.
note that such references are optional; they may or may not be there,
depending on the level of security you want. The final reference is to
an entity in a demographic service.
Now my question, how can we facilitate an EHR-construction, as described
in the documentation, using the available archetype-editors?
can you be more precise about what you mean here - building an EHR
itself is not the business of an archetype editor....
A problem is that I must figure the whole thing out by myself, and a misunderstanding can easily slip into mind.
I was thinking, that an EHR is build of data, and those data are all in objects derived from Locatable, Pathable, and so have archetype-details (except for the EHR-class itself), so an archetype-editor could be useful when constructing an EHR. Because in the EHR class there is need for a Party_Ref (which points to the Locatable-derived Party) in the EHR-Status (which is Locatable), I thought, an archetype-editor could be handy when filling up the whole thing.
That is how I come to think that an archetype is needed to construct the top of the EHR (with exception for the EHR itself), maybe I misunderstand?
Another question, how do people from the NHS, who built many many
archetypes, but none on demographic base construct their EHR's?
in the NHS so far there is no real EHR, only something called PSIS aka
the 'Spine' (see
[http://www.connectingforhealth.nhs.uk/resources/systserv/spine-factsheet](http://www.connectingforhealth.nhs.uk/resources/systserv/spine-factsheet)).
This has only a very basic architecture at the moment. They have not
really decided on an EHR architecture yet.
That makes it a lot clearer, it is very good what they share with us. I am very thankful for that.
Or is it more or less that that we are to use the Party-ref as an
Object-ref, and do not take the specifications to literally? (because,
they, f.e. will be updated in the future)
can you be more precise here?
I guess, I explained it above? The question is, can we use an object_ref in EHR-status for subject instead of a Party_ref, as described in the docs?
Do you think it is permitted to interpreted the specs that loosely? (sorry to ask a personal question)
Bert