On 10/10/2017 16:26, Birger Haarbrandt wrote:
Hi Thomas,
sorry for the late answer, I just came back from my vacation. For our
project, we would certainly like to start with commercial openEHR
repos for the larger sites. From my understanding, most products of
the bigger openEHR vendors are
Hi Thomas,
sorry for the late answer, I just came back from my vacation. For our
project, we would certainly like to start with commercial openEHR repos
for the larger sites. From my understanding, most products of the bigger
openEHR vendors are ready for ADL 2. If I'm wrong on that, we need t
I forgot to mention that we will probably (almost certainly) upgrade the
structure of terminology bindings to allow more meta-data, and we will
probably upgrade the annotations to allow more data types. Technically
speaking, both of these are breaking changes, but as ADL2 is not in use
outsid
On 01/10/2017 09:06, Birger Haarbrandt wrote:
Hi Thomas,
in Germany, we really would like to start our "green field" project
using ADL 2 for reasons like this. We would highly appreciate if the
official governance tools of the openEHR Foundation would start to
support ADL 2 very soon so that
Hi Thomas,
in Germany, we really would like to start our "green field" project using ADL 2 for reasons like this. We would highly appreciate if the official governance tools of the openEHR Foundation would start to support ADL 2 very soon so that we don't have to migrate eventually.
Best,
Birge
Everyone, thanks a lot for all your comments and feedback.
@Lars, yes both things are not exclusive, but modeling small archetypes
makes template ids not needed at the query level.
I agree with your point of the difficulty of keeping track of templates in
queries, since at some point we might wa
In ADL2 it doesn't really matter. THe only difference is that in an ADL2
template, specialisations are local 'overlays' inside the patient
template, rather than distinct archetypes in the archetype library.
In which case, you should specialise with archetypes as long as the
archetypes are li
: Re: Modeling generic concepts, considerations for querying
I agree with this one. Option 1 would create a kind of forest of dependencies,
many many archetypes in complex hierarchic systems, like SNOMED in the endnodes.
I don't think anyone would want this.
Option 2 is the option represent
I agree with this one. Option 1 would create a kind of forest of
dependencies, many many archetypes in complex hierarchic systems, like
SNOMED in the endnodes.
I don't think anyone would want this.
Option 2 is the option represents the power of OpenEHR.
By the way, SNOMED also supports higher h
I also recommend to use option 2. The most powerful feature of the openEHR
approach is to have the concepts builds as lego blocks, the maximum data,
aiming they can be reused in several scenarios.
That let out of the messy spaces of specialist systems, each one modeling
their own vision of concep
Hi due to
We developed a UK oriented termsrt as the LOINC based list used by HL7 CDA
was too US oriented but the principle is identical. We will probably apply
the term to composition name/value which allows mappings rather than the
templateid. Both are available to AQL
Ian
On 26 Sep 2017 at 10
Hi Pablo,
I am not a clinician but as an implementer I see the benefits of less
specific archetypes quite often. The fundamental role of archetypes is
reuse. It is so by design and templates solve the problem of composition
(in the object oriented sense, not the RM type).
I think the rule I try t
templates could be a
governable way to handle this problem.
Regards,
Silje
From: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] On
Behalf Of Heather Leslie
Sent: Tuesday, September 26, 2017 10:56 AM
To: For openEHR clinical discussions
Subject: RE: Modeling generic concepts
I agree with Ian that we should probably use a real 'coded' approach? I
believe HL7 uses Loinc for that. Spanish MoH has also proposed snomed terms
for each entry in the national archetypes. Maybe we can explore something
like this before trying to create our own pseudoterminology
2017-09-26 11:10
Hi Heather
That is pretty well my approach too. I think we will start yo see more
formal coding of composition names to be able to accurately identify the
content. In the UK we have developed a document name SNOMED subset for this
purpose and will also use this for ihe xds metadata.
Ian
On 26 Se
Hi Pablo,
The modeller’s dilemma!
If you make clinical synopsis more specific then how many variations will there
be in the end? We will end up with zillions of variations of all the generic
archetypes which will be an absolute governance nightmare.
I would prefer to see the queryable filter m
16 matches
Mail list logo
