odel-designers, the
war is not over yet, and it will never be. There will be great ideas
which need an own Reference Model.
Being prepared for that is a good thing.
Best regards
Bert
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20140625/df01d505/attachment.html>
Hi Ian,
As I come to think about it, it is a bit different, then I thought
yesterday it was.
Because a Reference Model, HISA, or some HL7 document, or OpenEHR, they
can be mimicked by a Reference Model without semantics.
But it is only the structure you mimic, and that works fine.
But is you a
On 25-06-14 11:43, Heather Leslie wrote:
> Hi all,
>
> I'm just going to chip in here because we see a lot of discussion about
> drawbacks of the openEHR ENTRY types, but not a lot of endorsement. After 8
> years of modelling archetypes, I find that the ENTRY classes work really
> well, and this
generic form of ENTRY; this is what let's the 'thousand flowers
bloom', but doesn't prevent proper reference structures being in the RM
either. In the near future we will fix this.
- thomas
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20140625/d67d89d7/attachment-0001.html>
I might need Adam to help with the specifics but from memory, since we
implemented a problem oriented care plan, we had a set of goals that may be
relevant for a specific problem, the targets relevant to a goal, the type of
data representation of the target (e.g text, single value, range, less
Hi Heath,
That is very interesting. Can you give an example of the kind of
metadata you are storing externally? I don't see the problem per-se
with having term-driven models but perhaps that is because a UK
perspective is always a bit more comfortable with this approach, but I
also understand how
Hi Bert,
As ever these are interesting discussions and the 'no semantics' in
the reference model approach has some attractions. I happen to agree
with Hugh that it seems that one way or other, there are a set of
generic semantic constructs which need to be broadly and tightly
adhered to, and cont
Hi all,
I'm just going to chip in here because we see a lot of discussion about
drawbacks of the openEHR ENTRY types, but not a lot of endorsement. After 8
years of modelling archetypes, I find that the ENTRY classes work really well,
and this is subsequently borne out in implementation. For ex
Hi All,
Based on our experience working with goals and targets in our Care Planning
system in Australia, the use of specialised Goals is not viable option from an
implementation perspective. The specialisation I am talking about is a little
different to what has been discussed so far as we were
Hi Hugh,
It is indeed a discussion which runs for several years.
I mentioned 13606 but it can also be done in OpenEHR. OpenEHR also has
lists, trees, clusters, elements, all derived from Locatable, thus
archetypeable.
So you can define (what I call) an information model, based on the
generic s
10 matches
Mail list logo