sed on the SNOMED CT structure, we
> have been doing that for a while
> https://www.youtube.com/watch?v=JIolq3b_Gkw=5=PL-4c1WHznyulrf8wPhaOq7T0E2QWQMCHH
>
> On Mon, Mar 25, 2019 at 1:03 AM Erik Sundvall
> wrote:
>
>> Hi all openEHR+Snomed CT hackers!
>>
>> Doing the inf
If the idea is to get openEHR data based on the SNOMED CT structure, we
have been doing that for a while
https://www.youtube.com/watch?v=JIolq3b_Gkw=5=PL-4c1WHznyulrf8wPhaOq7T0E2QWQMCHH
On Mon, Mar 25, 2019 at 1:03 AM Erik Sundvall wrote:
> Hi all openEHR+Snomed CT hackers!
>
&
Hi all openEHR+Snomed CT hackers!
Doing the inference described below using a reasoner and openEHR with AQL+api
calls as a bridge to EHR content would be pedagogical.
Who in the openEHR community will get a demo video out first?
Good luck with this little challenge!
Best regards,
Erik
> mapping could do the trick, as then you can tell where the unit comes from
>> and allows you to provide a "code" which could either contain a Snomed code
>> or a UCUM expression. Inputs are appreciated as always :)
>>
>
> I think your suggested so
alternatives are being explored in order to not break current
units definitions. Maybe adding an optional codephrase or terminology
mapping could do the trick, as then you can tell where the unit comes
from and allows you to provide a "code" which could either contain a
Snomed code
to not break current units
definitions. Maybe adding an optional codephrase or terminology mapping
could do the trick, as then you can tell where the unit comes from and
allows you to provide a "code" which could either contain a Snomed code or
a UCUM expression. Inputs are appreciated
can also occur in another standard, for example SNOMED,
also a UCUM-unit can occur in SNOMED, but is it sure it means the same?
Normally we are very prudent about things like this.
I found a HL7 wiki about this. Someone did some thinking about this. I
think that also applies to OpenEhr.
http
imply add the wanted SNOMED codes to the Template. This works well for
> smaller subsets . One example may be found in the URL below.
> Unfortunately the examples are Norwegian, but I guess you will find the
> relevant elements .
>
> https://github.com/bjornna/dips-ckm/blob/nymaster/
We simply add the wanted SNOMED codes to the Template. This works well for
smaller subsets . One example may be found in the URL below. Unfortunately
the examples are Norwegian, but I guess you will find the relevant elements .
https://github.com/bjornna/dips-ckm/blob/nymaster/templates
Dileep,
There are various things to consider
1. bind the SNOMED codes you want in the archetype term_binding section
2. consider how you design your templates, in the sense of what codes -
the internal, or the SNOMED get stored at runtime.
3. consider how the CDR implementation Operational
Hi,
I am trying to model some archetypes using coded text. The option values
should ideally come from SNOMED. Currently we do not have access to a
terminology service and so we are using Internal codes to achieve what we
want.
However we would like recorded values to also include their SNOMED
I understand from the discussion that there are different levels of
quality, and also some concepts are worked out completely unusable for
the purpose I talked about three days ago (generating archetypes from
SNOMED structures. The idea was not only quite naive, but also quite
controversial
Hi,
Just to add some historical context - SNOMED evolved from a terminology
designed to be a Reference Terminology (as opposed to Interface/Clinical
Terminology) at a time where ontologies were non existent or very primitive
(<90s). Hence the poor formal ontological commitment as of to
or SNOMED CT concepts to use.
When selecting how to represent the use cases when the information is from a
situation with explicit context you need to investigate which alternatives you
have and which of the possible alternative that are the best alternative. If
the EHR system you use only can
Interesting, the idea that SNOMED-concepts could need some
status-attributes.
When thinking about that, there could be attributes to serve other
purposes too.
Maybe the enormous amount of knowledge collected in SNOMED is not used
as extensively as possible.
There may be much more potential
a code string containing
terms from the Qualifiers hierarchy, but the user orgs have been told to
'avoid the Qualifiers hierarchy'?
The record hierarchy just doesn't belong in SNOMED CT. IAO / OBI maybe.
I would have much less of a problem if the 'use status' of these
hierarchies was clearer
Thomas,
I fully agree,
as you know, already.
Gerard
Gerard Freriks
+31 620347088
gf...@luna.nl <mailto:gf...@luna.nl>
> On 29 apr. 2016, at 16:42, Thomas Beale <thomas.be...@openehr.org> wrote:
>
> Hi Bert
> Erik and Ian partly answered this, but it is always worth re
Ian,
I need to correct you.
1- CIMI and SNOMED.
The nodes are NOT labeled using SNOMED, but LOINC is used.
SNOMED is reserved for the data fields.
2- SNOMED is a Reference Terminology and should in the ideal world be
orthogonal to structures as used in HL7v2, v3, and 13606.
The natural role
On 29/04/2016 18:02, Ian McNicoll wrote:
Hi Bert,
"I think that every leaf-node in an Archetype can be encoded in SNOMED,
don't you think?"
I'm afraid not even close, especially when you take into account the
changes in the meaning of datapoints that apply when used in differing
cont
of the nuances in the language.)
Regards
Mikael
From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On
Behalf Of Ian McNicoll
Sent: den 29 april 2016 23:05
To: For openEHR technical discussions
Subject: Re: SNOMED
Hi
Hi Mikael,
I really did not intend my remarks about the 'missing' content in SNOMED-CT
to be seen as a complaint, or criticism. I fully understand that this, by
definition, is work in progress and there is a perfectly good change
request mechanism to have new terms added.
I was only responding
Hi Tom,
Most of the concepts in the situation hierarchy had probably been added because
they have been useful in EHR systems without advanced information models and
without the possibility to post-coordinate and they are probably still in
SNOMED CT because some of these EHR systems are still
further by the attempts to represent
informational, timing and context-related entities in SNOMED CT.”
Are the clearly separated sub-hierarchy called “Situation with
explicit context”
(http://browser.ihtsdotools.org/?perspective=full=243796009=en-edition=v20160131=http://browser.ihtsdotools.org/api
On 29/04/2016 16:28, Bert Verhees wrote:
Thanks Thomas,
I read your text a few times, and now I think I understand what you
are saying.
You say that SNOMED (first remark is not of that high quality to be
useful for this purpose) is too extended, too many datapoints, and
many useless
I agree with all, most of the terms are difficult to be translated to
archetypes. What it is possible using snomed is to specify the
valuesets of a given data element by using the snomed expression
constraint syntax. We have been experimenting with it for a while, we
have even put an execution
On 29-04-16 18:02, Ian McNicoll wrote:
Hi Bert,
"I think that every leaf-node in an Archetype can be encoded in
SNOMED, don't you think?"
I'm afraid not even close, especially when you take into account the
changes in the meaning of datapoints that apply when used in differing
in SNOMED.
It is not a perfect solution.
Therefore I am glad you mention the low hanging fruit, and maybe it
is more then "some", maybe it is a lot.
So let us concentrate on that, and see where we would be able to come.
Yes, let's see. I'm still a skeptic though ;)
* the
Hi Bert,
"I think that every leaf-node in an Archetype can be encoded in SNOMED,
don't you think?"
I'm afraid not even close, especially when you take into account the
changes in the meaning of datapoints that apply when used in differing
contexts. When doing modelling for histopa
Hi Bert,
comments below!
On 2016-04-29 17:04, Bert Verhees wrote:
Hi Daniel, thanks, I posted the idea also to some Dutch groups, one
argument was that there is no workflow in SNOMED.
It is not a perfect solution.
Therefore I am glad you mention the low hanging fruit, and maybe it is
more
Hi,
I can just add that those entities Tom mentions below as
"The waters are muddied further by the attempts to represent informational,
timing and context-related entities in SNOMED CT."
Are the clearly separated sub-hierarchy called "Situation with explicit
Thanks Thomas,
I read your text a few times, and now I think I understand what you are
saying.
You say that SNOMED (first remark is not of that high quality to be
useful for this purpose) is too extended, too many datapoints, and many
useless datapoints for a clinician to be able to do his
remembering that
> SNOMED CT, if based on proper ontological principles, contains assertions
> that represent entities in the real world. This means taxonomy (IS-A) and
> properties, qualities, possible relationships and so on (see BFO2
> <https://www.google.co.u
Hi Daniel, thanks, I posted the idea also to some Dutch groups, one
argument was that there is no workflow in SNOMED.
It is not a perfect solution.
Therefore I am glad you mention the low hanging fruit, and maybe it is
more then "some", maybe it is a lot.
So let us c
Hi Bert
Erik and Ian partly answered this, but it is always worth remembering
that SNOMED CT, if based on proper ontological principles, contains
assertions that represent entities in the real world. This means
taxonomy (IS-A) and properties, qualities, possible relationships and so
on (see
Dear All,
while there may be some benefit in cross pollination between SNOMED CT
and archetypes, and while there also may be some low-hanging fruit in
bridging the semantics of both models (pre- or post-coordinated
laterality would be an often mentioned example) in general I'm a skeptic
Thanks Erik, for your reply. I did some more thinking in the meantime.
In SNOMED you have disorders, and they have attributes, and we all know
there are thousands of them. Writing so many archetypes is impossible,
and probably not necessary, but when you take in account to limit the
number
You can do some very clever things with Snomed CT especially if using
"post-coordination" in a good way. Sadly many current EHR-systems can't
utilize that power of Snomed CT fully. Clever archetyping with e.g. some
built in post-coordination-generating logic combined with some ext
archetypes
from SNOMED concepts, it would be possible to generate them, with
attributes and so on.
In a few hours time, one would have a complete forest with archetypes,
including ontology in more languages.
Maybe some smart handling, filtering, combining can create a better
collection, also looking
far it is feasible and useful to create archetypes from
SNOMED concepts, it would be possible to generate them, with attributes
and so on.
In a few hours time, one would have a complete forest with archetypes,
including ontology in more languages.
Maybe some smart handling, filtering, combining
I am following this discussion with great interest, just wanted you and
Michael to know, just in case you would want to stop it or have it
private, which I would regret.
Bert
On 30-09-15 09:20, Thomas Beale wrote:
ok - so the query would be applied to instances in a drug database
(each
(AMT)
since July 2014 (one release per month).
Michael
Sent from my iPhone
On 1 Oct 2015, at 6:43 PM, David Moner
<dam...@gmail.com<mailto:dam...@gmail.com>> wrote:
Hello,
At this point I think that is the only option. I want to believe that the
SNOMED CT Expression Constraint
Hello,
At this point I think that is the only option. I want to believe that the
SNOMED CT Expression Constraint Language has been designed with a future
evolution of SNOMED CT in mind, where concepts will be enriched with
numerical values. For example, SNOMED CT now contains a set of Virtual
Hi Michael,
in that case, to what information base or DB could the amoxycillin query
be applied? What is it for?
thanks
- thomas
On 29/09/2015 23:19, michael.law...@csiro.au wrote:
Hi Thomas,
These constraints are essentially queries over the snomed definitional
content (ie
Imagine instead the example was using the corresponding AMT concepts (since
snomed pure doesn't have any concrete domain modelling -- I.e. numeric values).
Then the focus concept would be the AMT amoxycillin Medicinal Product concept
2141501136100 and the constraint matches would be MPUUs
On 30/09/2015 07:51, michael.law...@csiro.au wrote:
Imagine instead the example was using the corresponding AMT concepts
(since snomed pure doesn't have any concrete domain modelling -- I.e.
numeric values).
Then the focus concept would be the AMT amoxycillin Medicinal Product
concept
Mikael
-Ursprungligt meddelande-
Från: openEHR-clinical [mailto:openehr-clinical-boun...@lists.openehr.org] För
Hardiker Nicholas
Skickat: den 28 september 2015 18:58
Till: For openEHR clinical discussions <openehr-clini...@lists.openehr.org>
Ämne: RE: openEHR and IHTSDO (SNOMED CT)
The latest version of the SNOMED CT constraint language
<http://snomed.org/expressionconstraint>proposes expressions like the
following:
Section 6.3
To find those capsules that have a strength between 500 and 800 mg
(inclusive), the following expression constraint may b
Hi Thomas,
These constraints are essentially queries over the snomed definitional content
(ie the Relationships), not queries over external data (ie not EHRs). The
intent is to identify sets of snomed concepts that satisfy the constraint
criteria. These sets could be subsequently used to join
Hi Tom,
I found the responsible person at IHTSDO for the collaboration with openEHR
Foundation. According to her, there are active discussions to be able to soon
sign a collaborative agreement between IHTSDO and openEHR and then continue to
work with how SNOMED CT and openEHR artefacts
referencing URIs for example.
- thomas
On 25/09/2015 18:26, Mikael Nyström wrote:
Hi,
I wonder if there are any current collaborations or collaboration plans between
openEHR Foundation and IHTSDO (which is the organisation that owns and
maintains SNOMED CT.)
Regards
Mikael
Hi,
I wonder if there are any current collaborations or collaboration plans between
openEHR Foundation and IHTSDO (which is the organisation that owns and
maintains SNOMED CT.)
Regards
Mikael
___
openEHR-technical mailing list
discussions;For openEHR technical
discussions;Subject:openEHR and IHTSDO (SNOMED CT)Hi,I wonder if there are any
current collaborations or collaboration plans between openEHR Foundation and
IHTSDO (which is the organisation that owns and maintains SNOMED CT.)
Regards
for other terminologies.
2015-04-27 13:49 GMT+02:00 Luis Marco luismarco at gmail.com:
Hi,
I am trying to annotate a set of archetypes with SNOMED-CT. I have noticed
that in the archetype editor, when I introduce a postcoordinated
expressions, the editor deletes the bars and creates a continuous
implementation discussions
Cc: openeh technical
Subject: Re: SNOMED-CT postcoordination support in ADL
Hello Luis,
I think having available a terminology service is some kind of a prerequisite
(which I don't agree with). I think openEHR should probably assume the IHTSDO
postcoordination
Hello,
I?m trying to get a terminology binding to an external terminology of SNOMED-CT.
I?ve already read some articles about mapping Entries afterwards onto SNOMED-CT.
This is not what I want.
I would like to have Live query to SNOMED-CT while entering the data into an
Archetype.
I?ve read
Hello Peter,
thank you for your fast responding to my email. I followed your advice and
downloaded the Editor from Ocean informatics. I also tried to bind a textfield
with SNOMED-CT 2002.
But I don?t really now if it works. When I go to the Interface where I should
be able to choose a code
Hi all,
Any thoughts on the possibility of using the SNOMED approach to term rubrics
(i.e 403234567|Some SNOMED term|) to make the human identification of
atNodes and archetypeIDs easier in documentation and AQL statements
i.e. node_identifier|rubric|?
The rubric aspect is purely for human
Hi Thomas,
Since January 2010 is the status ?Limited? is handled as an inactive value.
(See SNOMED CT Technical Reference Guide Appendix B.)
Greetings,
Mikael
From: openehr-technical-boun...@chime.ucl.ac.uk
[mailto:openehr
Nystr?m wrote:
Hi Thomas,
Since January 2010 is the status Limited is handled as an inactive
value. (See SNOMED CT Technical Reference Guide Appendix B.)
Greetings,
Mikael
*
*
-- next part --
An HTML
*
* As part of reviewing SNOMED CT Release Format 2 (RF2) and Reference
Sets specifications, I have created some diagrams which are available
here:
http://www.openehr.org/wiki/pages/viewpageattachments.action?pageId=10387459
So far I have a class diagram, and semantic net diagrams
On 11/03/2010 11:59, Stef Verlinden wrote:
For those of you interested in the 'problems' within Snomed as an ontology,
here (http://precedings.nature.com/documents/3465/version/1) you can find a
good and recent article describing them. This doesn't mean we shouldn't use
Snomed, but knowing
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20091021/d225fa38/attachment.html
Kent Spackman made a presentation on how SNOMED should be used to
represent complex clinical statements, using a design pattern approach.
This idea is clearly important in our thinking in openEHR on how to
connect the information models (archetypes) to terminology. See
http://www.openehr.org
Greg Caulton wrote:
So I guess ultimately the question boils down to what is
everyone/anyone else doing
- OpenEHR
- OpenEHR + LOINC
- OpenEHR + SNOMED
- All (tough especially as each system has its own set of terms and
concepts of what is what)
*the mapping work still largely has
Greg Caulton wrote:
The problem with SNOMED mapping ([...]) is that I assume (perhaps
incorrectly) that the OpenEHR foundation could not distribute the
mapping without the recipients first getting some kind of license
for the SNOMED - not insurmountable but that does complicate things
Hi,
One of the things that has been holding me up is the conundrum around
coded clinical documentation.
I would use OpenEHR exclusively but as I delve into the depths of
integration I am getting nervous that the archetypes have not yet been
mapped to LOINC or SNOMED.
As an example comparison
Greg Caulton wrote:
So I guess ultimately the question boils down to what is
everyone/anyone else doing
- OpenEHR
- OpenEHR + LOINC
- OpenEHR + SNOMED
- All (tough especially as each system has its own set of terms and
concepts of what is what)
*the mapping work still largely has
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070108/b1412187/attachment.html
-- next part --
___
openEHR-technical mailing list
query ids in archetypes (remember - these are what is mapped to
the 'ac' codes; you can still put snomed or whatever codes in the 'at' code
binding part if you want).
None of this is simple and it has taken both us (in the industrial context)
and the Manchester group over 5 years from
. The use of URLs whose meaning will not change over
time is
not to be taken lightly...
[...]
A safe URL is needed for each clinical terminology authority. (e.g.
standards are managed by ISO, Standards Australia etc.; SNOMED UK
and SNOMED AUS may have country specific needs
standardised and therefore evaluatable by any
terminology service containing an instance of snomed-ct, then we would
probably design the URL to simply indicate the terminology and the query
id. But - since the id of the query will make sense against multiple
terminologies (i.e. any kind of infection
, and the patient was travelling at the
time or subsequently emigrated).
the main thing that needs to be known is if snomed-ct-AUS is a proper
superset of snomed-ct-INT (or however these variants will be
designated); i.e. that there are no incompatibilities between the two.
On storing a new event
An HTML attachment was scrubbed...
URL:
http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20070106/87fcadb6/attachment.html
-- next part --
___
openEHR-technical mailing list
The point of the demonstration was that you could make snomed easier for
clinicians to use by creating these subsets ie medication route. These
subsets to be useful would need to be defined at a jurisdictional level or
higher so that everyone can use the same one. This allows for a change
constraining the solutions. I just worry that
with complex terminologies like snomed being used more often
it may be useful to have an inbetween solution i.e.
simplest)
list of codes typed in '123123', '3242342', '123123'
* moderate *)
simple langauge like limit depth 5 (is_a('102323','arm
binding
to snomed are excellent. I was just wondering about this
quote..
The intended purpose of archetypes is to empower clinicians
to define the content, semantics and data-entry interfaces of
systems independently from the information systems [1].
Archetypes were selected because
are retrieved
in the latter instance. In the demo that I did at the Oz snomed conference
in December, I showed how the term set can be defined using the Ocean
terminology service, and in this particular instance, it was mapped to a web
service running in another state of Australia. This is really just
discussion. Many of
the points about the difficulties of doing archetype binding
to snomed are excellent. I was just wondering about this
quote..
The intended purpose of archetypes is to empower clinicians
to define the content, semantics and data-entry interfaces of
systems independently
Thanks for the much clearer explanation Hugh.
Is there a power point presentation (pref the Oz Snomed Conf) and/or
paper(s) about your work that you can share with us?
Thanks
Rahil
Hugh Leslie wrote:
Hi All
The Ocean Archetype Editor allows the designer to map one or more
coding
Hi,
Dear Andrew,
On 3-jan-2007, at 14:40, Andrew Patterson wrote:
Just thinking long term, just say some archetype was defined for
some little used data entry. The archetype (which includes a URL
term binding) is put into the clinical system. Some data matching
the archetype is entered -
standardisation of data for
safe and accurate data interoperability. The MoST automated
system was used to generate a list of candidate SNOMED CT
code mappings. The paper discusses the semantic issues
which arose when generating lexical and semantic matches of
terms from the archetype model to relevant
81 matches
Mail list logo
