Archived Collabnet Discussions
Content Project Discussion Forum
difference between immunization and vaccination (collabnet topic id: topc1455)
| Title | Content | Created By | Date Created | ID | Topic ID |
|---|---|---|---|---|---|
| difference between immunization and vaccination | There is a difference between immunization and vaccination. i. Stedman’s: Vaccination is the act of administering a vaccine (any preparation intended for active immunologic prophylaxis; e.g., preparations of killed microbes of virulent strains or living microbes of attenuated (variant or mutant) strains; or microbial, fungal, plant, protozoal, or metazoan derivatives or products) ii. Immunization includes not only vaccination but also passive immunization. iii. So it is not technically correct to assign Bordetella vaccine (substance) as the direct substance in the procedure "immunization for Bordetella (procedure)". c. Should we change the FSN of the existing "Immunization for bordetella (procedure)” to "Vaccination for bordetella (procedure)” and define it accordingly, since in practical usage, the term means 'active immunization’? d. Or should we simply recommend post-coordination of a subtype as “Administration of vaccine to produce active immunity (procedure) 33879002 by refining the Direct substance, (in this case, Bordetella vaccine (substance). e. Submitter says their system does not handle role-grouping well, and they have been simply post-coordinating a direct substance of the particular vaccine without role-grouping it with an action of administration. f. Also, currently Administration of vaccine to produce active immunity (procedure) 33879002 is primitive. g. Can we fully define this, given that Stedman defines “vaccine” as “essentially any preparation intended for active immunologic prophylaxis; e.g., preparations of killed microbes of virulent strains or living microbes of attenuated (variant or mutant) strains; or microbial, fungal, plant, protozoal, or metazoan derivatives or products.” h. Pre-coordinate a new concept for the submitter request? | kspackman | Fri Mar 26 21:52:12 Z 2010 | post1791 | topc1455 |
Problem List Refsets Overlap (collabnet topic id: topc6016)
| Title | Content | Created By | Date Created | ID | Topic ID |
|---|---|---|---|---|---|
| Problem List Refsets Overlap | Convening a group of interested individuals to discuss some analysis of the content and overlap of several problem list refsets. | phernandez | Tue Jul 30 16:18:27 Z 2013 | post8772 | topc6016 |
| Re: Problem List Refsets Overlap | Additional Document for reference: GPFP Refset Description | phernandez | Tue Jul 30 16:19:18 Z 2013 | post8773 | topc6016 |
| Re: Problem List Refsets Overlap | Thank you for posting all the information in one place. Whilst academically it is interesting to compare the similarities (or not) between refsets with what may appear similar use cases I think it is important to keep in mind the purpose of the work. If the intention is to produce a single refset that would replace these individually created ones I think it would be wise to consider how it is going to be maintained since this may affect how the initial content is developed. If new refset content (or content removals) are subject to some kind of evaluation with is an overhead on the maintainance organisation and additionally may result in the submitting organisations still needing to create their own versions of the refset to ensure that they have the content they need. This could bring into question the value of a single centrally created refset. | emelhuish | Wed Jul 31 12:05:35 Z 2013 | post8776 | topc6016 |
| Re: Problem List Refsets Overlap | Thanks for setting this up as a discussion thread. Probably my first question is where are things going from here? Has there been a subgroup set up? Can we have a summary of areas that you would you like input on via the thread? From my understanding the rationale for this analysis was the potential for a start set for a problem list. From the July minutes this could have a Primary Care or commonly used focus. My initial suggestion is more clearly defining things such the use case, the specialities/ domains of practice this is aimed at, determining the range of content and level of granularity required etc. and then determining which of the current subsets (and is there others) are suitable to provide the sources of data. Has interest been raised by NRC’s/organisations in having this available? What would be beneficial for them? In relation to questions raised on maintenance, there would be a range of considerations- who will maintain it, how- replacement of retired content, should it be reviews of source data to determine changes (frequency of that) and/or input from users. Documentation: we produce a reference library document here that goes out with each release. What do other NRC's provide? Cheers, Cathy | crichardson | Tue Aug 06 00:07:00 Z 2013 | post8786 | topc6016 |
| Re: Problem List Refsets Overlap | I agree with the comments by Emma and Cathy, and it has become quite clear that IHTSDO will need to document the way a refset is produced and its intended uses; and will need to put in place maintenance processes for any refset that is officially released. IHTSDO can't support a large number of overlapping refsets, but probably can handle more than one, as long as there is a reason to do so. I think we already see the reason in this case. I'd like to suggest that we already have clear evidence that the two GP/FP refsets are produced with a different purpose and intended uses, and have a different maintenance process, than the other sets, and therefore the content committee could make a recommendation for IHTSDO to officially release three different sets (the two GP/FP refsets, and one additional refset), with an explanation of the different purposes, uses, specialties, and maintenance processes. | kspackman | Mon Aug 12 19:03:28 Z 2013 | post8803 | topc6016 |
| Re: Problem List Refsets Overlap | This looks like a sensible proposal. I'd be inclined to support the NLM CORE set as the 'other' international offering. By virtue of the fact that it is a pooled product, it's less likely to have the tight coupling to requirements that the GP/FP sets have, but nevertheless it probably hits a nice balance between being considerably smaller than 'unconstrained' SNOMED CT but at the same time being big enough to behave like a 'proper' terminology (not a toy) in a variety of settings. In particular I can picture it being a useful seed set for dozens of academic activities (e.g. modularisation projects, navigation hierarchy development, testing of novel quality assurance techniques [as Ray indicates] etc.), and also as a credible and recognisable starter set for clinical demonstrator systems. Depending how much time/resource can be committed, its membership could either be fixed from this release (and only respond to historical inactivations), be updated according to changes in the original source sets, or be influenced by other similar sets as they are identified. Whatever, so long as it was made clear that this was a derivative set (essentially published for experimentation and research) and not one coupled to a precise context/use case, I imagine that it would be warmly received by many SNOMED CT users (and potential users) during this phase in the product's evolution. Kind regards Ed | edcheetham | Tue Aug 13 15:52:32 Z 2013 | post8805 | topc6016 |
| Re: Problem List Refsets Overlap | Nick asked for a brief description of the NLM CORE Subset, so I'll repeat here what was buried in the initial email thread. The CORE Problem List Subset is derived from problem list (or equivalent) datasets from 8 healthcare institutions (7 in US, 1 in Hong Kong). These institutions are large-scale, mixed inpatient-outpatient facilities that cover most major medical specialties (including Internal Medicine, General Surgery, Pediatrics, Obstetrics, Gynecology, Psychiatry and Orthopedics). We use a frequency-based cut-off of 95% of total usage, and map the local terms to SNOMED CT. About 8% of the local terms within the cut-off are considered not mappable to SNOMED CT. Since its first publication in 2009, the subset underwent one major update in 2012 with the incorporation of a new data source from the Veterans Administration. Most of the terms in the VA dataset was already in the Subset, and only 320 (5%) new concepts needed to be added. This is anecdotal evidence that a relatively stable subset representing the commonly used problem list concepts is achievable. The primary goal of the CORE Subset is to serve as a starter subset in clinical implementation, but it has also been used in other activities according to reports in the literature, including quality assurance, terminology research, mapping and decision support. I think publishing the CORE Subset as an international refset will increase users' awareness of it and improve availability. The CORE Subset serves a different use case from the GP/FP refsets and they are complementary to each other. Best regards, Kin-Wah | kfung | Tue Aug 13 17:15:39 Z 2013 | post8807 | topc6016 |
cataract vs opacity (collabnet topic id: topc2687)
| Title | Content | Created By | Date Created | ID | Topic ID |
|---|---|---|---|---|---|
| cataract vs opacity | Regarding the newly posted content project "artf220828: cataract vs opacity": "...Description: Consider retiring Cataract (morphologic abnormality) and Redefine cataract procedures currently using cataract morphology with morphology opacity and finding site lens to be consistent with modeling of cataract disorders..." I can see the value in aligning procedures and observations where morphology is common to both. I just wonder whether it is possible to explore the argument for favoring the site-neutral 'opacity' over the site-associated 'cataract' (I can't conceive of a cataract that doesn't occur in a lens). I one sense this is attractive (morphology modelling is no longer overloaded with site), but I wonder whether this is a realistic change pattern. Looking at the descendants of 'degenerative abnormality' alone, there are many values whose use is either explicity or implicitly applicable to particular body structures or tissue types (e.g. glomerulosclerosis, demyelination). If we site-neutralise our modelling of cataract disorders and procedures, we may persuade ourselves we have to do the same for other structures. Or is there a 'big book of morphologic abnormalities' (i.e. an external authority) that doesn't recognise cataract? Incidentally - whatever change pattern is pursued, we should ensure that the content beneath 'cataract (finding)' is similarly treated. | edcheetham | Wed Nov 03 10:58:44 Z 2010 | post3387 | topc2687 |
stroke (collabnet topic id: topc3123)
| Title | Content | Created By | Date Created | ID | Topic ID |
|---|---|---|---|---|---|
| stroke | Looking at concepts addressing stroke. Our local neurology departments driving a variety of decision support and reporting, based on snomed concepts, relevant to problem list use cases. I'm noticing that 1) cerebral infarction is not in the stroke hierarchy; 2) detail is not complete with regard to a stroke appearing in a particular vascular territory. I didn't find any projects pertaining to stroke in the list, and wondering if we need to add one? Howard | hgoldberg | Tue Jun 21 19:01:13 Z 2011 | post4492 | topc3123 |
| Re: stroke | In looking at how to relate ischemic stroke and cerebral infarct; clinically, it appears to be that an ischemic stroke is a stroke that is due to a cerebral infarct. The fly in the ointment here is that traumatic cerebral infarcts caused by trauma are not deemed to cause strokes, a patient who suffers a traumatic cerebral infarct as a result of traumatic brain injury is not considered to have had a stroke. One option is certainly to create the concept non-traumatic cerebral infarct, declare this disjoint traumatic infarcts, and define ischemic stroke in terms of a non-traumatic infarct. The traumatic / non-traumatic disorder pattern appears quite often, and would require the addition of numerous non-traumatic disorder concepts if this were Snomed policy. But the classification machinery would work correctly in preventing inconsistent concepts or instances. Conversely, this could be addressed as a styleguide issue, where it would be less of an issue for terminologists adding to SCT, but be a potential source of inconsistencies in end-user use cases. I didn't find any issues relating to traumatic / non-traumatic disorder pairs in the tracker. I'm wondering what other people's thoughts are as to what the policy should be. Regards, Howard | hgoldberg | Wed Jul 20 21:17:31 Z 2011 | post4803 | topc3123 |
| Re: stroke | The traumatic / non-traumatic issue is mentioned in some detail in the Editorial Guide. I agree we need a project to propose a solution that will work for stroke, as well as other disorders that are understood implicitly to exclude the results of direct physical trauma (which may or may not have the word "injury" in their FSN). For those who might not have immediate access to the Editorial Guide section I'm referring to: 6.1.3.11. Trauma, injury, damage The word “trauma” has multiple senses. The first distinction is physical damage to the body versus psychic trauma. We assume “trauma” means physical damage unless accompanied by words that make clear it is psychic. Traumatic injury (disorder) is defined as any disorder with a morphology of "traumatic abnormality". See known issues (below) for a discussion of the known problems with traumatic morphologies. There is a problem that occurs if we attempt to require “injury” to be synonymous with “trauma” which can be best illustrated by the example of the very common usage of the word “injury” when referring to damage to the brain. An internet search for the phrase "non-traumatic brain injury" will show that this refers to brain damage that is the result of asphyxiation, stroke, drowning, toxic injury, etc., and not due to direct physical impact to the skull (the traumatic brain injuries). We needed a broad category that would allow us to categorize injuries broadly including non-traumatic ones. The concept created for this purpose is traumatic and/or non-traumatic injury (disorder). 6.1.3.11.1. Laceration, incised wound, rupture, traumatic rupture, spontaneous rupture: The word “lacerated” has two meanings, which can be succinctly summarized as “torn” vs “cut”. Common clinical usage equates “laceration” with “incised wound”. For example, a common emergency room problem is accidental cuts of fingers with kitchen knives. These are routinely called “lacerations”. On the other hand, most dictionaries insist that “laceration” implies a wound with ragged edges as a result of tearing. Obstetrical lacerations carry this latter meaning. When structures are torn or ruptured, the edges are usually irregular. There are two morphologies with a synonym of “laceration”: "incised wound", and “traumatic rupture”. Modelers must choose which of these two meanings is intended when the word “laceration” or “lacerated” appears in a concept description from the “injury” hierarchy. More generally, ruptures can occur either as a result of injury or spontaneously. The word “rupture”, when applied to muscles and tendons, implies a traumatic injury (e.g. "rupture of collateral ligament of the knee"). But “rupture” when applied to an internal viscus may be either traumatic or spontaneous (e.g. rupture of aorta, rupture of ovary, etc). “Rupture” has subtype morphologies “traumatic rupture” and “nontraumatic rupture”. It is important to make this distinction, at a minimum, in order to support queries related to the effects of trauma. Modelers should choose “traumatic rupture” as the value of Associated-morphology for concepts using the word “rupture” with anatomical sites (such as muscles and tendons) where rupture requires trauma, in the absence of a specific lesion. Modelers should choose “rupture” as the value of Associated-morphology for concepts using the word “rupture” with sites (such as internal organs) where both traumatic and spontaneous rupture are seen. Nontraumatic rupture is usually stated to be so, but may also be inferred if the thing rupturing is a lesion which ordinarily leads to spontaneous rupture in the absence of trauma (e.g. rupture of inflamed appendix). | kspackman | Wed Jul 20 21:29:25 Z 2011 | post4804 | topc3123 |
SUBJECT RELATIONSHIP CONTEXT values (collabnet topic id: topc1448)
| Title | Content | Created By | Date Created | ID | Topic ID |
|---|---|---|---|---|---|
| SUBJECT RELATIONSHIP CONTEXT values | Subject relationship context means the statement is about this entity [in relation to] the subject of the record It would be considered "overloading" to use the same attribute when we want to subclass the subject of the record according to the subject's relationship to some other entity. Examples: Avoid role overloading: SRC = father of subject: means this is about the father of the subject of the record. Vs SRC = subject as father: means this is about the subject of the record who is in the role of father (of someone). And avoid quality overloading: SRC = fetus of subject. This is about the fetus of the subject of the record. Vs. SRC = fetus as subject of record. This is about a fetus who is the subject of the record. | kspackman | Thu Mar 25 16:07:16 Z 2010 | post1784 | topc1448 |
Episode of care and pregnancy complications (collabnet topic id: topc1456)
| Title | Content | Created By | Date Created | ID | Topic ID |
|---|---|---|---|---|---|
| Episode of care and pregnancy complications | 4.2.2.1 Example: episode of care and pregnancy complications For example, ICD-9-CM adds a series of complicated “episode of care” phrases to several of the categories of disorders affecting pregnancy and delivery. Here is the full set of “fifth digit” modifiers for complications related to pregnancy: The following fifth-digit subclassification is for use with categories 640-649 to denote the current episode of care: 0 unspecified as to episode of care or not applicable 1 delivered, with or without mention of antepartum condition Antepartum condition with delivery Delivery NOS (with mention of antepartum complication during current episode of care) Intrapartum obstetric condition (with mention of antepartum complication during current episode of care) Pregnancy, delivered (with mention of antepartum complication during current episode of care) 2 delivered, with mention of postpartum complication Delivery with mention of puerperal complication during current episode of care 3 antepartum condition or complication Antepartum obstetric condition, not delivered during the current episode of care 4 postpartum condition or complication Postpartum or puerperal obstetric condition or complication following delivery that occurred: during previous episode of care outside hospital, with subsequent admission for observation or care The first task is to strip away all “mention of” and “unspecified” phrases, and then determine whether there is still a URU meaning. A fifth digit of “0” generates no special meaning for SNOMED and the phrase “unspecified as to episode of care” would be rejected as invalid for an FSN. Therefore SNOMED cannot incorporate any code that corresponds to the “0” fifth digit here. A fifth digit of “1” means that the current episode of care involved delivery and the complication finding was antepartum. Some submitters might want to have a short phrase that says something like "finding X, delivered", where the finding occurred antepartum and the mother was delivered during the current episode of care. This constitutes two statements and our recommendation would be to place each statement in the patient record separately. However, given the request for a single pre-coordinated code that captures both meanings, it is possible to use the SNOMED CT context model, with two role groups, to capture the two statements. A specific code, 641.91, would carry the ICD-9-CM phrase “Unspecified antepartum hemorrhage, delivered, with or without mention of antepartum condition”. Obviously there is a great deal of revision required to make this acceptable (even marginally) to SNOMED. The “unspecified” and “with or without mention of” phrases must be dropped. Clarification must be added to indicate whether it is the mother or fetus who is the subject of the record. The “episode of care” meaning is hard to capture in SNOMED and would be largely unrepresentable. This process might result in an FSN that says "history of antepartum hemorrhage, mother delivered (situation)", which could be defined as: Situation, {associated-finding = antepartum hemorrhage, temporal-context = past}, {associated -finding = mother delivered, temporal-context = current or specified} This expression does not completely capture all the subtle meanings associated with the ICD-9-CM code 641.91, but it is perhaps as close as we can come without major changes. In general, pre-coordination of such codes is to be denigrated and discouraged because of the false sense of completeness it gives to those seeking to link SNOMED and ICD-9-CM (the meanings are not the same and cannot be), and because of the added complexity such compositional expressions may present to decision support algorithms, particularly those that require automated processing of temporal relationships. In the example given, a statement in a patient record using this code cannot tell us when the antepartum hemorrhage took place. It only tells us that it was sometime in the past – prior to delivery. The expression as given actually matches cases where the antepartum hemorrhage took place in a prior pregnancy. This temporal linkage problem would be avoided by using two statements with two time stamps, one coding the complication (and recording the time when it occurred) and the other one for the delivery. | kspackman | Fri Mar 26 23:38:53 Z 2010 | post1792 | topc1456 |
recurrent malignant neoplasm (collabnet topic id: topc1450)
| Title | Content | Created By | Date Created | ID | Topic ID |
|---|---|---|---|---|---|
| recurrent malignant neoplasm | History of recurrent malignant neoplasm of breast (disorder) a. We are suggesting post-coordination of the History of X concept but this means we need to make: Recurrent malignant neoplasm of breast (disorder) IS_A Malignant neoplasm of breast (disorder) Clinical course: Recurrent (qualifier value) i. There is the potential for requests for many “Recurrence of malignant neoplasm of X” concepts. ii. Do we make Recurrent malignant neoplasm of breast (disorder) or do we suggest they also postcoordinate this concept as shown above? We are already suggesting postcoordination of the History of… piece. 1. Additional issues: a. Should these be named using “recurrent” or “recurrence”? b. Is a recurrence necessarily at the site of the primary? (what about lymphoma/leukemia where the site is diffuse?) c. Is there a difference between a recurrence and a metastasis? iii. Defer on creating these until we get clear guidance on the meaning. 1. CAP-STS will look into whether there are any clear definitions for recurrent neoplasm iv. Once there is clear guidance on the meaning, a project to refine how malignancies should be modeled in SNOMED is needed. These would be a kind of “Recurrent disease”. v. In the meantime, suggest the postcoordination shown above. If they can do expressions, then can do “history of X” where X is also postcoordinated. vi. suggestion of how to postcoordinate Recurrent malignant neoplasm of X (disorder) to the postcoordination table: IS_A Malignant neoplasm of X (disorder) Clinical course: Recurrent (qualifier value) | kspackman | Thu Mar 25 17:31:56 Z 2010 | post1786 | topc1450 |
Style guide in DITA coordinated on Subversion (collabnet topic id: topc1008)
| Title | Content | Created By | Date Created | ID | Topic ID |
|---|---|---|---|---|---|
| Style guide in DITA coordinated on Subversion | We need to post our entire Style Guide, formatted in DITA, onto a repository that is coordinated via Subversion, with documents generated using Maven (both pdf and html documents), and the html documents should be posted on the ihtsdo.org web site, exact location there to be determined. We'll call this the style guide pilot acceptance testing of the CollabNet environment. | kspackman | Wed Jan 21 23:20:18 Z 2009 | post1019 | topc1008 |
Acute X-itis (acute inflammatory disorders) (collabnet topic id: topc1449)
| Title | Content | Created By | Date Created | ID | Topic ID |
|---|---|---|---|---|---|
| Acute X-itis (acute inflammatory disorders) | From: plivesay@vt.edu Sent: Monday, May 12, 2008 7:28:23 AM To: Monique van Berkum (s) Cc: Kent Spackman Subject: Acute inflammatory disorders Hi Kent, Monique, I had asked some time back "Should disorders with FSNs "Acute Xitis" be defined with: 1. An "acute inflammation (morphologic abnormality)" 2. Clinical course Sudden onset AND/OR short duration (qualifier value) 3. Both of the above At the moment, most seem to be modeled only with the morphology. Is this correct?" Kent, you had replied, >>This is one of those "necessarily also" conditions: If the morphology is "acute inflammation", then the clinical course should be sudden onset etc. For now I think we have decided to do BOTH when these situations occur. Long term we need general concept inclusion axioms (GCIs) to handle this automatically.<< Is it official policy that "acute Xitis" should be modeled with both a morphology of "acute inflammation" and a clinical course "Sudden onset and/or short duration"? We have a lot of these concepts (a quick search on "acute*itis* pulled up 744 concepts in TDE) and none of the ones I checked have a clinical course. Even if the policy is definite, it seems unlikely that we will fix these before the next release. For now, should I add requested new concepts with both the course and the morphology, knowing that they will be inconsistent with existing content? Or use just the morphology and assume that they will be fixed in a later mass update of acute inflammatory disorders? Thanks, Penny | kspackman | Thu Mar 25 16:13:20 Z 2010 | post1785 | topc1449 |
orders -- instructions -- care planning and sentence function types (collabnet topic id: topc1460)
| Title | Content | Created By | Date Created | ID | Topic ID |
|---|---|---|---|---|---|
| orders / instructions / care planning and sentence function types | Subject RE: procedure editorial policy From Casey Anne To Kent Spackman Cc mvanber@cap.org Sent Wednesday, December 16, 2009 1:09 AM Agreed! Your explanation is good – maybe put that in as the principle with the rules afterwards? Anne From: Kent Spackman [mailto:ksp@ihtsdo.org] Sent: 16 December 2009 06:51 To: Casey Anne Cc: mvanber@cap.org Subject: RE: procedure editorial policy Agreed. The usual sentence (and phrase) function types are declarative, interrogative, imperative, and exclamatory. (http://en.wikipedia.org/wiki/Sentence_function ) SNOMED CT procedures should name a procedure, and as such they should be orthogonal to (not committed to) a categorization as declarative, interrogative, imperative or exclamatory. I think maybe this is the principle underlying the past tense proscription. For example, “hand tendon ganglion excised” is clearly a declarative phrase, and breaks the rule, whereas “excision of ganglion” can’t be categorized by sentence function because it isn’t a sentence. If you agree, I can make a proposal along these lines to put into a revision to the style guide. Thanks, --Kent From: Casey Anne [mailto:Anne.Casey@RCN.ORG.UK] Sent: Monday, December 14, 2009 12:55 AM To: Kent Spackman Subject: procedure editorial policy Hi Kent We are discussing care planning concepts in SNOMED CT in the UK and I can’t remember if we ever agreed the rules about orders / instructions. In the general style guide we have: Past tense verbal forms must not be used, since they invoke a temporal context for procedures, indicating that the procedure was done. Existing terms containing past tense verbs will be moved to the context-dependent hierarchy. For example: hand tendon ganglion excised should instead be phrased: excision of ganglion of tendon of hand Do we / should we have: Order / instruction ‘tense’/ phrasing must not be used, since it invokes a temporal context indicating that the procedure is to be done. For example, feed via naso gastric tube should instead be phrased: feeding via naso gastric tube; monitor blood pressure should be phrased blood pressure monitoring Thoughts?? Anne Anne Casey Adviser in Information Standards Royal College of Nursing 20 Cavendish Square London W1G 0RN, UK Tel: +44 (0) 207 647 3747 Email: anne.casey@rcn.org.uk ---------------------------------------------------------------------------------------------------------- http://www.rcn.org.uk This email is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Royal College of Nursing or any of its affiliates. If you are not the intended recipient be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please return it to the sender immediately. The contents of this message may be legally privileged. Royal College of Nursing of the United Kingdom 20 Cavendish Square London W1G ORN Registered Charity Number: 276435 Tel: +44 (0) 845 456 3996 Fax: +44 (0) 20 7647 3436 Email has been scanned for viruses by Altman Technologies' email management service ---------------------------------------------------------------------------------------------------------- http://www.rcn.org.uk This email is confidential and intended solely for the use of the individual to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Royal College of Nursing or any of its affiliates. If you are not the intended recipient be advised that you have received this email in error and that any use, dissemination, forwarding, printing or copying of this email is strictly prohibited. If you have received this email in error please return it to the sender immediately. The contents of this message may be legally privileged. Royal College of Nursing of the United Kingdom 20 Cavendish Square London W1G ORN Registered Charity Number: 276435 Tel: +44 (0) 845 456 3996 Fax: +44 (0) 20 7647 3436 | kspackman | Wed Apr 07 06:19:19 Z 2010 | post1796 | topc1460 |
Fetal situations (collabnet topic id: topc3951)
| Title | Content | Created By | Date Created | ID | Topic ID |
|---|---|---|---|---|---|
| Fetal situations | Are there any style guide recommendations for representing situations of the fetus with respect to the problem list? In the prenatal context of the mother, it would seem the subject of record should be the fetus; in the antenatal context, the problem would seem to be a fetal disorder. I didn't see any 'fetal <disorder>' in the pre-coordination tracker. | hgoldberg | Sat Nov 05 02:36:58 Z 2011 | post5691 | topc3951 |
| Re: Fetal situations | Hi Howard The requirements here are recognised to be complex and incompletely addressed (see e.g. 6.1.4.8. in the current Editorial Guide for a commentary on the anatomical/occurence overlap). Regarding an SRC approach to fetus/fetal, please see the attached work, which I began in 2006 and Kent reanimated in 2009. Pages 5-12 of the document (which tackles SRC values in general) consider fetal representations specifically. The complexity of the result isn't pretty - the complexity resutling from an attempt to manage the consequences of making all references to fetal findings and disorders "situations" (see the the a, b c list on page 6). It may be that these concerns is misguided (which would simplify the solution), but this is as far as the work progressed. So, there is no firm editorial guidance at the moment. The current SRC vallue constraint (< 125676002 | person) is known to be inadquate and needs extending for other non-subject of record values. The problem with pre-adopting fetus (specifically) is that it is already partially represented in other axes (body structures and occurrences) which may make reliable data processing harder. Agree it's an important representational issue. Ed | edcheetham | Mon Nov 07 10:10:18 Z 2011 | post5703 | topc3951 |
CABG (collabnet topic id: topc6553)
| Title | Content | Created By | Date Created | ID | Topic ID |
|---|---|---|---|---|---|
| CABG | While working on our Cardiology refset, I have found 90205004 |Cardiac revascularization with bypass anatomosis (procedure)|, which is a child of |heart revascularization (procedure)|. We would like confirmation whether this is synonymous with 232717009 | Coronary artery bypass grafting (procedure)|. If it is, then I would like to suggest that it should be made synonymous, and children of 232717009 |Coronary artery bypass grafting (procedure)| be moved as well under the parent |heart revascularization (procedure)| | isulaiman | Thu Mar 13 03:13:16 Z 2014 | post9703 | topc6553 |
| Re: CABG | Ismat, I am encouraged to see another post. My question is just two before yours on this forum, but it was over two years ago. Does anyone responed to posts on this forum? Is there a better forum for these kinds of questions? | chowell | Thu Mar 13 13:28:11 Z 2014 | post9704 | topc6553 |
| Re: CABG | Thank you for the reply everybody. This is one of the topic that we will submit and discuss with the content developer team. I was thinking of initiating this discussion here and see others feedback, and if they have encountered similar finding or request. | isulaiman | Thu Mar 13 22:55:14 Z 2014 | post9706 | topc6553 |
progressive (collabnet topic id: topc2651)
| Title | Content | Created By | Date Created | ID | Topic ID |
|---|---|---|---|---|---|
| progressive | (chronic) progressive coccidioidomycosis: This is a chronic course, but "chronic progressive" is not one of the values allowed for clinical course. Suggest we add this as a new value, and retire the old "progressive (qualifier value)" as MAYBE-A "chronic progressive". | kspackman | Mon Sep 20 22:41:21 Z 2010 | post3255 | topc2651 |
Comments on tracker items and linkage with discussion threads (collabnet topic id: topc2951)
| Title | Content | Created By | Date Created | ID | Topic ID |
|---|---|---|---|---|---|
| Comments on tracker items and linkage with discussion threads | Dear CC, I am playing around with collabnet and I found it quite practical to use the comment function in the tracker for quick remarks. We had discussed this in a TCon, and there was the suggestion to create a new discussion thread for each content tracker item. I confess that I feel more at ease for spontaneous comments using the tracker comment functionality than broadcasting it to all CC members (and flooding them with e-mail messages). I think we should have both options. As the adressees of tracker comments I see primarily the IHTSDO terminologists, whereas for items to be broadly discussed in the CC I would use the Collabnet discussion function. Comments can be easily referred to by pasting the respective link, e.g. https://csfe.aceworkspace.net/sf/go/artf6257#6 into a discussion thread. Thus, tracker-internal comments can be easily brought to a broader audience whenever deemed appropriate. Stefan | sschulz | Thu Apr 07 12:41:35 Z 2011 | post4062 | topc2951 |
| Re: Comments on tracker items and linkage with discussion threads | Stefan's comments on the tracker items are very welcome and I think the people working on projects would appreciate having this type of input. I would hope that the comments on the tracker will be comments about the item itself; comments about comments, which are likely to generate replies from the original commenter, could prompt a discussion forum entry - in the Content Project Discussion Forum (project: IHTSDO), as Stefan suggests. Discussions about committee approvals, balancing projects, workload, priorities, and planning could I think be handled in the Committee Discussions Forum (project: Content Committee). | kspackman | Thu Apr 07 17:33:46 Z 2011 | post4064 | topc2951 |
implantation and implants (collabnet topic id: topc1451)
| Title | Content | Created By | Date Created | ID | Topic ID |
|---|---|---|---|---|---|
| implantation and implants | What is an implant? A device Relationship to prosthesis? What is implantation? (insertion of a device? Or insertion with securing firmly/permanently in place?) Implantation action was retired and replaced by insertion. However, there are two different meanings of implantation: 1) Introduction such that the introduced entity is secured firmly or deeply in place so that it can become permanent; versus not secured at all, such that it can fall out or slip out, or merely attached loosely or transiently, as with tape or a loose suture (e.g. an endotracheal tube is taped to the mouth or nose, but this is not "fixed"). 2) Introduction of a device that is made to remain in place and provide some structural or functional benefit; exclusive of transplantation. Related meanings: Transplantation Requires that the material object be taken from a biological source analogous to the target location or function, and introduced in such a way that it can be (or become) structurally or functionally effective. Grafting Requires fixation Permanence: Permanent, temporary Object: substance, device, Biological device, transplant tissue/organ, non-biological device Means: surgical, surgical fixation What's the difference between surgical introduction and surgical insertion? (? Insertion has a device object?) To graft: To surgically introduce and secure in place but not connect a blood supply. If it is living tissue, it obtains a blood supply from the new vascular bed. If it is not living tissue, then it needs no blood supply. To implant: To surgically introduce and secure permanently in place a device (as opposed to material). The implant is inert with respect to body growth. To surgically transplant: To surgically introduce and connect blood supply to transplant material. Proposal for new surgical introduction action hierarchy: Surgical introduction - action Surgical introduction and securing in place - action Surgical transplantation - action Surgical implantation - action Reimplantation - action Surgical grafting - action The existing concept “implantation (procedure)” appears to be ambiguous. It has non-synonymous synonyms “insertion” and “insertion procedure”, and even “implant procedure”. It is MAYBE-A “grafting (procedure)”, and it is MAYBE-A (new) “surgical placement of non-biological device (procedure)”. [ But I do think an _implant_ can properly be defined as a non-biological device designed for permanent introduction into the body. ] | kspackman | Thu Mar 25 18:07:09 Z 2010 | post1787 | topc1451 |
hepatopancreatic ampulla and common bile duct (anatomy and specimens) (collabnet topic id: topc2790)
| Title | Content | Created By | Date Created | ID | Topic ID |
|---|---|---|---|---|---|
| hepatopancreatic ampulla and common bile duct (anatomy and specimens) | Question: should specimens from the ampulla of Vater (hepatopancreatic ampulla) be regarded as specimens from the common bile duct? (a request submission suggests they should not). FMA and SNOMED both consider the hepatopancreatic ampulla as the terminal part of the common bile duct. FMA also has a "common bile duct proper" which ends on merging with the pancreatic duct to form the ampulla (aka ampulla of Vater). Possible actions in response to the request: * adding a new concept "specimen from common bile duct proper", * adding a text definition to "specimen from common bile duct" indicating that it includes entire length (ampulla included) * changing the anatomy model so that SNOMED's common bile duct concept corresponds to FMA's "common bile duct proper" [ not recommended because of divergence ] * other? | kspackman | Fri Feb 04 19:23:22 Z 2011 | post3682 | topc2790 |
| Re: hepatopancreatic ampulla and common bile duct (anatomy and specimens) | The concerns in the original request seem to result from two inferences in the current data viewed as false: (1) Ampulla of vater(AoV) IsA Common Bile Duct structure (CBD) (where the requester views the latter as the 'proper' structure). and (2) 'AoV' IsA 'Pancreatic structure' Both these seem to originate in the anatomy representation (and ? manifest in disorders/procedures as well as specimens), so the changes should probably be here, rather than localised to specimens. (2) could be addressed by severing the current 'duodenal papilla structure' IsA 'pancreatic duct structure'. Less clear about (1) - what would be the disbenefit of adding a 'CBD duct proper' concept to SNOMED? Not sure how this would relate to the other descendants of CBD structure (79741001), but with sufficient clarity (e.g. text definition here, not in specimens) the distinction required by the requester could be made, without changing the meaning of CBD structure. Ed | edcheetham | Mon Feb 07 15:20:30 Z 2011 | post3687 | topc2790 |
allergic disorder and immune hypersensitivity disorder (collabnet topic id: topc1454)
| Title | Content | Created By | Date Created | ID | Topic ID |
|---|---|---|---|---|---|
| allergic disorder and immune hypersensitivity disorder | Our merger of "allergic disorder" with "immune hypersensitivity disorder" is not correct. Allergic disorder means "external" allergic, i.e. it excludes autoimmunity. But "immune hypersensitivity disorder" per se will include autoimmunity. We need to be sure that the "immune hypersensitivity disorder by mechanism" is not a child of allergic disorder. Bruce Goldberg has volunteered tol produce a proposed definition of "allergic disorder" Many authors clearly delineate allergy and autoimmune disease: Celiac disease http://celiacdisease.about.com/od/whatisceliacdisease/f/AllergyVsAutoim.htm clearly an autoimmune disease and NOT an allergy to gluten. Other authors cite IgE-mediated processes in autoimmune disease, and thus subclass autoimmune disease with those diseases involving an allergic response. (!) BUT autoimmune hypersensitivity reactions can be type II, III, or IV. Type I allergy is a classical Th2-driven hypersensitivity disease based on IgE recognition of environmental (exogenous) allergens. Trends in Immunology, Volume 30, Issue 3, 109-116, 23 February 2009 doi:10.1016/j.it.2008.12.004 Linking allergy to autoimmune disease Rudolf Valenta, Irene Mittermann, Thomas Werfel, Holger Garn and Harald Renz Abstract Type I allergy is a classical Th2-driven hypersensitivity disease based on IgE recognition of environmental allergens. Exposure of allergic individuals to exogenous allergens leads to immediate type inflammation caused by degranulation of mast cells via IgE-allergen immune complexes and the release of inflammatory mediators, proteases and pro-inflammatory cytokines. However, allergic inflammation can occur and persist in the absence of exposure to exogenous allergens and might paradoxically resemble a Th1-mediated chronic inflammatory reaction. We summarize evidence supporting the view that autoimmune mechanisms might contribute to these processes. IgE recognition of autoantigens might augment allergic inflammation in the absence of exogenous allergen exposure. Moreover, autoantigens that activate Th1-immune responses could contribute to chronic inflammation in allergy, thus linking allergy to autoimmunity. | kspackman | Thu Mar 25 20:39:20 Z 2010 | post1790 | topc1454 |
Culprit lesion of coronary artery (collabnet topic id: topc4121)
| Title | Content | Created By | Date Created | ID | Topic ID |
|---|---|---|---|---|---|
| Culprit lesion of coronary artery | I am new to this forum. Please excuse me if this is not the right place for this question. We, Agfa Healthcare Cardiovascular Business Unit, are modelling PCI procedures for clinical reporting, and are puzzled about 371895000|Culprit lesion of coronary artery|. This, surprisingly, is not a disorder. Also, in our usage, it is a statement about another, more detailed, finding in the same report, a coronary artery stenosis. What would be a reasonable post-coordinated expression relating these two findings? | chowell | Fri Dec 02 14:02:39 Z 2011 | post5939 | topc4121 |
illumination techniques (collabnet topic id: topc1458)
| Title | Content | Created By | Date Created | ID | Topic ID |
|---|---|---|---|---|---|
| illumination techniques | because DICOM uses illumination-action values, they should be moved not retired, when changing to techniques. | kspackman | Wed Mar 31 16:54:53 Z 2010 | post1794 | topc1458 |
STEMI -- NSTEMI myocardial infarction (collabnet topic id: topc3970)
| Title | Content | Created By | Date Created | ID | Topic ID |
|---|---|---|---|---|---|
| STEMI / NSTEMI myocardial infarction | Appears to be important to express STEMI / NSTEMI MI's occurring in a myocardial wall distribution, especially with respect to ICD-10, ICD-10CM. Currently, there are singleton concepts for each, but distribution subclasses under non-Q-Wave and Q-Wave MI's. NSTEMI's and non-Q-wave generally synonymous, not so for STEMI and Q-wave. Might be reasonable to use morphologies of transmural infarct and a new non-transmural infarct to define STEMI /NSTEMI | hgoldberg | Fri Nov 11 02:18:27 Z 2011 | post5730 | topc3970 |
Psoriasis, Graves disease and classification under allergic disorder (collabnet topic id: topc1453)
| Title | Content | Created By | Date Created | ID | Topic ID |
|---|---|---|---|---|---|
| Psoriasis, Graves disease and classification under allergic disorder | Subject RE: FW: Psoriasis, Graves Disease et al. From Rogers Jeremy (NHS Connecting for Health) To Bruce.J.Goldberg@kp.org; Kent Spackman Sent Monday, November 23, 2009 6:40 AM Thanks Bruce – very helpful. I have a feeling that this is but one of many similar situations where many clinicians will expect to see a more limited and heuristically defined set of concepts under some abstract clinical supertype but where SNOMED provides (what appears to them to be) an over-inclusive list that’s been constructed variously as a specialty/purist view, or (as in the following example) a logical view: 69031006|Excision of breast tissue (procedure)| (Syn:Mastectomy) currently subsumes e.g. 237378001|Incisional biopsy of breast (procedure)| and 12708000|Excision of accessory nipple (procedure)| Whilst I believe 100% that SNOMED should contain those ‘complete’ views, I think there will be a credibility/usability problem sooner rather than later because the other views aren’t there. But FWIW I don’t think that the best way to reinstate those views is by grafting them in as heuristically-defined alternate supercategories for browsing/reporting plus (necessarily) manually maintained IS-A hierarchies. I’d rather see that kind of stuff maintained at one remove from the pure formal ontology – e.g. as navigational refsets and/or subsets. Jeremy From: Bruce.J.Goldberg@kp.org [mailto:Bruce.J.Goldberg@kp.org] Sent: 19 November 2009 02:37 To: ksp@ihtsdo.org Cc: Rogers Jeremy (NHS Connecting for Health) Subject: Re: FW: Psoriasis, Graves Disease et al. Jeremy, Kent: I can explain the origins behind the development of this hierarchy which may clarify things a bit. One issue that was identified was coming up with a precise defintion for allergy. Becasue of the inherent ambiguity of defining an allergic disorder, we decided to adopt the definitions put forth by the WAO (world allergy organization) Allergy is a hypersensitivity reaction initiated by immunologic mechanisms Hypersensitivity is objectively reproducible symptoms or signs initiated by exposure to a defined stimulus at a dose tolerated by normal persons. Thus allergic disorder was equated as Immune hypersensitivity disorder. The hierarchy below is the Gel and Coomb's classification for hypersensitivity diseases. Admittedly, many of the diseases subsumed by these headers do not precisely fit the WAO definition of hypersensitivity disease but the classification although dated is still widely in use. Immune hypersensitivity disorder by mechanism Antibody-mediated activation and inactivation * Antibody-mediated cytolysis * Cell-mediated cytotoxic disorder * Delayed hypersensitivity disorder Hypersensitivity disorder mediated by immune complex IgE-mediated allergic disorder The disadvantage of the above is that disorders such as Grave's disease are classified as a type of allergy whereas many providers might be thinking more of IgE-mediated allergic disorder , allergic contact dermatitis and other specific diseases when referring to allergy. One possible solution would be to remove Allergic disorder as a synonym of Immune hypersensitivty disorder and create a separate Allergic disorder hierarchy as a child of Immune hypersensitivty disorder and populate it selectively with disorders more traditionally thought to be "allergic" Hypersensitivity disorder Immune hypersensitivity disorder Allergic disorder Allergic disorder by body site affected IgE mediated allergic disorder Non-IgE mediated allergic disorder Immune hypersensitivity disorder by mechanism Antibody-mediated activation and inactivation * Antibody-mediated cytolysis * Cell-mediated cytotoxic disorder * Delayed hypersensitivity disorder Hypersensitivity disorder mediated by immune complex IgE-mediated allergic disorder Nonimmune hypersensitivity disorder This preserves the distinction between IgE and non IgE mediated allergy and immune and non-immune hypersensitivity. I would also favor defining allergy with a pathological process of allergic disorder similar to autoimmune disease. In terms of psoriasis, I would not think of this as a cell-mediated cytotoxic disorder or as a hypersensitivity disorder. It may be thought of as disease characterized by chronic inflammation in the absence of a known infectious agent or antigen. I think is has been given the wrong parent. Bruce J. Goldberg, M..D., Ph.D. Chief of service, Department of Allergy, LAMC Director, S.C.P.M.G. Regional Allergy-Immunology Lab Kaiser Permanente HealthConnect Convergent Medical Terminology Phone: 323-783-4939 (office), 323-783-5896 (lab) Tie line: 8-363 NOTICE TO RECIPIENT: If you are not the intended recipient of this e-mail, you are prohibited from sharing, copying, or otherwise using or disclosing its contents. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and permanently delete this e-mail and any attachments without reading, forwarding or saving them. Thank you. "Kent Spackman" <ksp@ihtsdo.org> 11/18/2009 08:31 AM To Bruce J Goldberg/CA/KAIPERM@KAIPERM cc "Rogers Jeremy (NHS Connecting for Health)" <jeremy.rogers@nhs.net> Subject FW: Psoriasis, Graves Disease et al. Bruce, I wonder if you could look at Jeremy’s question and give an expert opinion as an allergist/immunologist? Thanks, --Kent From: Rogers Jeremy (NHS Connecting for Health) [mailto:jeremy.rogers@nhs.net] Sent: Wednesday, November 18, 2009 8:18 AM To: Kent Spackman Subject: Psoriasis, Graves Disease et al. Hi Kent, Is there a good explanation for why 9014002|Psoriasis (disorder)|, 353295004|Graves' disease (disorder)| and 91637004|Myasthenia gravis (disorder)| are all subtypes of 421668005|Immune hypersensitivity disorder (disorder)| (Syn: Allergic Disorder). I’d agree that they’re all immune-mediated but I didn’t think they counted as hypersensitivity (allergic) reactions. hypersensitivity hUcper-sen-si-tivci-tT Abnormal sensitivity, a condition in which there is an exaggerated response by the body to the stimulus of a foreign agent. See: allergy. Syn: hypersensitiveness. I get the feeling there’s a problem with the hierarchy around Allergic disorder Immune hypersensitivity disorder by mechanism Antibody-mediated activation and inactivation * Antibody-mediated cytolysis * Cell-mediated cytotoxic disorder * Delayed hypersensitivity disorder Hypersensitivity disorder mediated by immune complex IgE-mediated allergic disorder …where the asterisked concepts aren’t necessarily hypersensitivity. The current hierarchy has the effect of throwing Psoriasis et al into the Allergies section of some EPR summaries. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dr Jeremy Rogers MD MB ChB Principal Terminology Specialist NHS Connecting for Health Technology Office (Data Standards - Terminology Service) Princes Square, Leeds LS1 4HY +44 113 397 4404 (VOIP) jeremy.rogers@nhs.net www.connectingforhealth.nhs.uk | kspackman | Thu Mar 25 20:28:24 Z 2010 | post1789 | topc1453 |
users
Extension management (collabnet topic id: topc4338)
| Title | Content | Created By | Date Created | ID | Topic ID |
|---|---|---|---|---|---|
| Extension management | Hi All, Am I right in believing that extension management is not yet implemented in the Workbench? I can't find much about it in the documentation and it appears in the requirements document on this site. Many thanks - Christopher | cmarshall | Thu Mar 01 13:42:46 Z 2012 | post6308 | topc4338 |
| RE: Extension management | Christopher, The NLM is working on a release of the WB that addresses this issue. I have included Brian Carlsen on this response to give you the details of where we are to date. Jim James T. Case M.S., D.V.M., Ph.D. Health Program Specialist, SNOMED CT National Library of Medicine/NIH James.case@mail.nih.gov Cell: 301-412-9287 -----Original Message----- From: Christopher Marshall (ihtsdo UK) [mailto:Christopher.Marshall@clinithink.com] Sent: Thursday, March 01, 2012 5:43 AM To: general-ihtsdo Subject: Extension management Hi All, Am I right in believing that extension management is not yet implemented in the Workbench? I can't find much about it in the documentation and it appears in the requirements document on this site. Many thanks - Christopher _______________________________________________ users https://csfe.aceworkspace.net/sf/go/post6308 To cancel your subscription to this discussion, please e-mail general-ihtsdo-unsubscribe@csfe.aceworkspace.net | jcase | Thu Mar 01 14:18:08 Z 2012 | post6310 | topc4338 |
| RE: Extension management | Jim, Thanks for the response. This sounds promising and I look forward to seeing it when it is released. I do have a question of capability in the management of SNOMED CT IDs in use in the extension. Our extension is currently very small and has not been published so understanding what is being developed will help us prepare for it. Our requirement is to be able to subdivide our IDs into internal namespaces. Looking at a namespaced ID we have the following sections aaaaaaaa bbbbbbb cc d where: a = our assigned ID; b = IHTSDO assigned namespace; c = object type (e.g. concept, description, etc); d = check digit We need to be able to subdivide the 'a' space into different areas. To do this we were planning to reserve the last two digits for an internal namespace leaving 6 digits for the individual items. Is this a strategy that can be used with the proposed new functionality? If not do you provide another way of subdividing the ID space that we can use? Many thanks, again, for your help - Christopher -----Original Message----- From: Case, James (NIH/NLM) [E] [mailto:james.case@mail.nih.gov] Sent: 01 March 2012 14:17 To: general-ihtsdo@csfe.aceworkspace.net Cc: Carlsen, Brian (NIH/NLM) [C]; Srinivasan, Suresh (NIH/NLM) [E]; Carlsen, Brian (NIH/NLM) [C]; Srinivasan, Suresh (NIH/NLM) [E] Subject: RE: Extension management Christopher, The NLM is working on a release of the WB that addresses this issue. I have included Brian Carlsen on this response to give you the details of where we are to date. Jim James T. Case M.S., D.V.M., Ph.D. Health Program Specialist, SNOMED CT National Library of Medicine/NIH James.case@mail.nih.gov Cell: 301-412-9287 -----Original Message----- From: Christopher Marshall (ihtsdo UK) [mailto:Christopher.Marshall@clinithink.com] Sent: Thursday, March 01, 2012 5:43 AM To: general-ihtsdo Subject: Extension management Hi All, Am I right in believing that extension management is not yet implemented in the Workbench? I can't find much about it in the documentation and it appears in the requirements document on this site. Many thanks - Christopher _______________________________________________ users https://csfe.aceworkspace.net/sf/go/post6308 To cancel your subscription to this discussion, please e-mail general-ihtsdo-unsubscribe@csfe.aceworkspace.net _______________________________________________ users https://csfe.aceworkspace.net/sf/go/post6310 Christopher Marshall Clinithink Terminology Architect T. +44 (0)2921 250 192 F. +44 (0) 208 150 7818 UK M. +44 (0)7813 774 180 E. christopher.marshall@clinithink.com Skype. chrismarshall-clinithink www.clinithink.com<http://www.clinithink.com/> CLiX by Clinithink add meaning:get knowledge This email, including attachments, is from Clinithink Ltd and contains information that may be proprietary to the sender, privileged, non-public confidential information and/or otherwise exempt from disclosure under applicable laws, including, but not limited to privacy standards imposed pursuant to the federal Health Insurance Portability and Accountability Act of 1996 ("HIPPA") and is intended to be conveyed only to the designated recipient(s). If you are not an intended recipient, please delete this email, including attachments, and notify Clinithink Ltd. The unauthorised use, dissemination, distribution or reproduction of this email, including attachments, is prohibited and may be unlawful. Clinithink Ltd is a private company registered in England and Wales, Registered number. 6966031. Registered office: 2nd Floor, 145-157 St John Street, London EC1V 4PY, UK. | cmarshall | Fri Mar 02 12:10:27 Z 2012 | post6317 | topc4338 |
| RE: Extension management | Christopher, The plan you outline is exactly the proposed plan for assigning identifiers moving forward. Somewhere in the workbench spec (I will need to ask Brian to weigh in here as he was the one who told me about it first) there is the notion of "subprojects" within a namespace. This allows for the type of flexibility you are seeking and, in fact, is structure just as you outlined aaaaaa bb ccccccc dd e where: a = assigned ID; b = project ID; c = namespace ID; d = partitionID; e = check digit Assignment of these types of IDs has already been enabled in our local extension management processes and I am sure will be part of the extension-enabled WB release, but again, I refer to Brian for the gory details. So all in all I think your needs will be well met by the WB. Jim James T. Case M.S., D.V.M., Ph.D. Health Program Specialist, SNOMED CT National Library of Medicine/NIH James.case@mail.nih.gov Cell: 301-412-9287 -----Original Message----- From: Christopher Marshall [mailto:christopher.marshall@clinithink.com] Sent: Friday, March 02, 2012 4:10 AM To: general-ihtsdo@csfe.aceworkspace.net Cc: Carlsen, Brian (NIH/NLM) [C]; Srinivasan, Suresh (NIH/NLM) [E]; Carlsen, Brian (NIH/NLM) [C]; Srinivasan, Suresh (NIH/NLM) [E] Subject: RE: Extension management Jim, Thanks for the response. This sounds promising and I look forward to seeing it when it is released. I do have a question of capability in the management of SNOMED CT IDs in use in the extension. Our extension is currently very small and has not been published so understanding what is being developed will help us prepare for it. Our requirement is to be able to subdivide our IDs into internal namespaces. Looking at a namespaced ID we have the following sections aaaaaaaa bbbbbbb cc d where: a = our assigned ID; b = IHTSDO assigned namespace; c = object type (e.g. concept, description, etc); d = check digit We need to be able to subdivide the 'a' space into different areas. To do this we were planning to reserve the last two digits for an internal namespace leaving 6 digits for the individual items. Is this a strategy that can be used with the proposed new functionality? If not do you provide another way of subdividing the ID space that we can use? Many thanks, again, for your help - Christopher -----Original Message----- From: Case, James (NIH/NLM) [E] [mailto:james.case@mail.nih.gov] Sent: 01 March 2012 14:17 To: general-ihtsdo@csfe.aceworkspace.net Cc: Carlsen, Brian (NIH/NLM) [C]; Srinivasan, Suresh (NIH/NLM) [E]; Carlsen, Brian (NIH/NLM) [C]; Srinivasan, Suresh (NIH/NLM) [E] Subject: RE: Extension management Christopher, The NLM is working on a release of the WB that addresses this issue. I have included Brian Carlsen on this response to give you the details of where we are to date. Jim James T. Case M.S., D.V.M., Ph.D. Health Program Specialist, SNOMED CT National Library of Medicine/NIH James.case@mail.nih.gov Cell: 301-412-9287 -----Original Message----- From: Christopher Marshall (ihtsdo UK) [mailto:Christopher.Marshall@clinithink.com] Sent: Thursday, March 01, 2012 5:43 AM To: general-ihtsdo Subject: Extension management Hi All, Am I right in believing that extension management is not yet implemented in the Workbench? I can't find much about it in the documentation and it appears in the requirements document on this site. Many thanks - Christopher _______________________________________________ users https://csfe.aceworkspace.net/sf/go/post6308 To cancel your subscription to this discussion, please e-mail general-ihtsdo-unsubscribe@csfe.aceworkspace.net _______________________________________________ users https://csfe.aceworkspace.net/sf/go/post6310 Christopher Marshall Clinithink Terminology Architect T. +44 (0)2921 250 192 F. +44 (0) 208 150 7818 UK M. +44 (0)7813 774 180 E. christopher.marshall@clinithink.com Skype. chrismarshall-clinithink www.clinithink.com<http://www.clinithink.com/> CLiX by Clinithink add meaning:get knowledge This email, including attachments, is from Clinithink Ltd and contains information that may be proprietary to the sender, privileged, non-public confidential information and/or otherwise exempt from disclosure under applicable laws, including, but not limited to privacy standards imposed pursuant to the federal Health Insurance Portability and Accountability Act of 1996 ("HIPPA") and is intended to be conveyed only to the designated recipient(s). If you are not an intended recipient, please delete this email, including attachments, and notify Clinithink Ltd. The unauthorised use, dissemination, distribution or reproduction of this email, including attachments, is prohibited and may be unlawful. Clinithink Ltd is a private company registered in England and Wales, Registered number. 6966031. Registered office: 2nd Floor, 145-157 St John Street, London EC1V 4PY, UK. _______________________________________________ users https://csfe.aceworkspace.net/sf/go/post6317 To cancel your subscription to this discussion, please e-mail general-ihtsdo-unsubscribe@csfe.aceworkspace.net | jcase | Fri Mar 02 14:55:53 Z 2012 | post6318 | topc4338 |
| Re: RE: Extension management | Jim, Christopher, Can you explain why you would not just use Modules for this? They are far more flexible and do not suffer the *many* drawbacks of trying to partition what should be "meaningless identifiers". michael -- Dr Michael Lawley Principal Research Scientist The Australia e-Health Research Centre http://aehrc.com/ +61 7 3253 3609; 0432 832 067 | mlawley | Fri Mar 02 22:14:08 Z 2012 | post6321 | topc4338 |
| RE: RE: Extension management | Michael, That was my initial question when I learned about the project part of the ID, but I was informed that some people want to be able to have subprojects within a ModuleID space (for some reason). I agree that the ModuleID would be much cleaner, but I don't make the rules....:-) Jim James T. Case M.S., D.V.M., Ph.D. Health Program Specialist, SNOMED CT National Library of Medicine/NIH James.case@mail.nih.gov Cell: 301-412-9287 -----Original Message----- From: Michael Lawley (ihtsdo csiro) [mailto:michael.lawley@csiro.au] Sent: Friday, March 02, 2012 2:14 PM To: general-ihtsdo Subject: Re: RE: Extension management Jim, Christopher, Can you explain why you would not just use Modules for this? They are far more flexible and do not suffer the *many* drawbacks of trying to partition what should be "meaningless identifiers". michael -- Dr Michael Lawley Principal Research Scientist The Australia e-Health Research Centre http://aehrc.com/ +61 7 3253 3609; 0432 832 067 _______________________________________________ users https://csfe.aceworkspace.net/sf/go/post6321 To cancel your subscription to this discussion, please e-mail general-ihtsdo-unsubscribe@csfe.aceworkspace.net | jcase | Fri Mar 02 22:16:53 Z 2012 | post6322 | topc4338 |
| Re: RE: RE: Extension management | Thanks Jim, I think that was my question though - there is clearly "some reason" why this is wanted, but without having this reason explicitly articulated we will never know whether the solution is actually the best one for the problem, nor whether there is a use-case floating around that we don't yet know about or understand and for which Modules are insufficient. Of course namespace owners are free to partition and allocate the SCTIDs in their sub-space however they want according to their own rules, but my concern is that "internal" rules like these have a tendency to bleed out of an organisation and impact those on the outside. michael | mlawley | Sat Mar 03 05:06:22 Z 2012 | post6323 | topc4338 |
| RE: RE: RE: Extension management | Michael, I agree that there must be some reason; however, I am a bit concerned about this given the recent policy with regards to the movement of components from one namespace to another. In the case of the promotion of a concept from an extension to the core, the "projectID" part of the identifier no longer has any meaning since it has been removed from the context of its original creation. With the meaning of the namespace now representing the origin of the component instead of the ownership of the component, I question the value of the projectID. My personal preference would be to manage this using module "subIDs" that could all be recursively related to the main module owned by the namespace. If there are folks using the "projectID" in their assignments of IDs, I think many of us would love to hear the benefits over the use of moduleIDs. Jim James T. Case M.S., D.V.M., Ph.D. Health Program Specialist, SNOMED CT National Library of Medicine/NIH James.case@mail.nih.gov Cell: 301-412-9287 -----Original Message----- From: Michael Lawley (ihtsdo csiro) [mailto:michael.lawley@csiro.au] Sent: Saturday, March 03, 2012 12:06 AM To: general-ihtsdo Subject: Re: RE: RE: Extension management Thanks Jim, I think that was my question though - there is clearly "some reason" why this is wanted, but without having this reason explicitly articulated we will never know whether the solution is actually the best one for the problem, nor whether there is a use-case floating around that we don't yet know about or understand and for which Modules are insufficient. Of course namespace owners are free to partition and allocate the SCTIDs in their sub-space however they want according to their own rules, but my concern is that "internal" rules like these have a tendency to bleed out of an organisation and impact those on the outside. michael _______________________________________________ users https://csfe.aceworkspace.net/sf/go/post6323 To cancel your subscription to this discussion, please e-mail general-ihtsdo-unsubscribe@csfe.aceworkspace.net | jcase | Mon Mar 05 13:17:16 Z 2012 | post6325 | topc4338 |
| RE: RE: RE: Extension management | From our perspective it doesn't really matter. We are sufficiently early in our work and have yet to publish anything in our namespace so can rework what we have done. Our requirement is purely to aid management of IDs that we generate and given the lack of standard tooling using a project ID seemed the easiest way of doing it. If Modules would satisfy this requirement better could you point me to some documentation that I can review and I'll see if that makes more sense. Many thanks for your advice and help - Christopher -----Original Message----- From: Case, James (NIH/NLM) [E] [mailto:james.case@mail.nih.gov] Sent: 05 March 2012 13:17 To: general-ihtsdo@csfe.aceworkspace.net Subject: RE: RE: RE: Extension management Michael, I agree that there must be some reason; however, I am a bit concerned about this given the recent policy with regards to the movement of components from one namespace to another. In the case of the promotion of a concept from an extension to the core, the "projectID" part of the identifier no longer has any meaning since it has been removed from the context of its original creation. With the meaning of the namespace now representing the origin of the component instead of the ownership of the component, I question the value of the projectID. My personal preference would be to manage this using module "subIDs" that could all be recursively related to the main module owned by the namespace. If there are folks using the "projectID" in their assignments of IDs, I think many of us would love to hear the benefits over the use of moduleIDs. Jim James T. Case M.S., D.V.M., Ph.D. Health Program Specialist, SNOMED CT National Library of Medicine/NIH James.case@mail.nih.gov Cell: 301-412-9287 -----Original Message----- From: Michael Lawley (ihtsdo csiro) [mailto:michael.lawley@csiro.au] Sent: Saturday, March 03, 2012 12:06 AM To: general-ihtsdo Subject: Re: RE: RE: Extension management Thanks Jim, I think that was my question though - there is clearly "some reason" why this is wanted, but without having this reason explicitly articulated we will never know whether the solution is actually the best one for the problem, nor whether there is a use-case floating around that we don't yet know about or understand and for which Modules are insufficient. Of course namespace owners are free to partition and allocate the SCTIDs in their sub-space however they want according to their own rules, but my concern is that "internal" rules like these have a tendency to bleed out of an organisation and impact those on the outside. michael _______________________________________________ users https://csfe.aceworkspace.net/sf/go/post6323 To cancel your subscription to this discussion, please e-mail general-ihtsdo-unsubscribe@csfe.aceworkspace.net _______________________________________________ users https://csfe.aceworkspace.net/sf/go/post6325 Christopher Marshall Clinithink Terminology Architect T. +44 (0)2921 250 192 F. +44 (0) 208 150 7818 UK M. +44 (0)7813 774 180 E. christopher.marshall@clinithink.com Skype. chrismarshall-clinithink www.clinithink.com<http://www.clinithink.com/> CLiX by Clinithink add meaning:get knowledge This email, including attachments, is from Clinithink Ltd and contains information that may be proprietary to the sender, privileged, non-public confidential information and/or otherwise exempt from disclosure under applicable laws, including, but not limited to privacy standards imposed pursuant to the federal Health Insurance Portability and Accountability Act of 1996 ("HIPPA") and is intended to be conveyed only to the designated recipient(s). If you are not an intended recipient, please delete this email, including attachments, and notify Clinithink Ltd. The unauthorised use, dissemination, distribution or reproduction of this email, including attachments, is prohibited and may be unlawful. Clinithink Ltd is a private company registered in England and Wales, Registered number. 6966031. Registered office: 2nd Floor, 145-157 St John Street, London EC1V 4PY, UK. | cmarshall | Mon Mar 05 17:16:22 Z 2012 | post6326 | topc4338 |
| Re: RE: RE: RE: Extension management | Hi Chris, I think modules are definitely the way to go for what you describe as the allow de-coupling of the SCTID allocation from any kind of grouping concept. This then allows SCTIDs to move from "project" to "project" as needs change. Also, with the use of module dependencies, you can have "sub-projects" and so forth. The place to look is the RF2 (Release Format 2) documentation. michael | mlawley | Wed Mar 07 21:57:51 Z 2012 | post6336 | topc4338 |
| RE: RE: RE: RE: Extension management | Thanks for the pointer Michael. I'll have a look at that. - Christopher -----Original Message----- From: Michael Lawley (ihtsdo csiro) [mailto:michael.lawley@csiro.au] Sent: 07 March 2012 21:58 To: general-ihtsdo Subject: Re: RE: RE: RE: Extension management Hi Chris, I think modules are definitely the way to go for what you describe as the allow de-coupling of the SCTID allocation from any kind of grouping concept. This then allows SCTIDs to move from "project" to "project" as needs change. Also, with the use of module dependencies, you can have "sub-projects" and so forth. The place to look is the RF2 (Release Format 2) documentation. michael _______________________________________________ users https://csfe.aceworkspace.net/sf/go/post6336 Christopher Marshall Clinithink Terminology Architect T. +44 (0)2921 250 192 F. +44 (0) 208 150 7818 UK M. +44 (0)7813 774 180 E. christopher.marshall@clinithink.com Skype. chrismarshall-clinithink www.clinithink.com<http://www.clinithink.com/> CLiX by Clinithink add meaning:get knowledge This email, including attachments, is from Clinithink Ltd and contains information that may be proprietary to the sender, privileged, non-public confidential information and/or otherwise exempt from disclosure under applicable laws, including, but not limited to privacy standards imposed pursuant to the federal Health Insurance Portability and Accountability Act of 1996 ("HIPPA") and is intended to be conveyed only to the designated recipient(s). If you are not an intended recipient, please delete this email, including attachments, and notify Clinithink Ltd. The unauthorised use, dissemination, distribution or reproduction of this email, including attachments, is prohibited and may be unlawful. Clinithink Ltd is a private company registered in England and Wales, Registered number. 6966031. Registered office: 2nd Floor, 145-157 St John Street, London EC1V 4PY, UK. | cmarshall | Thu Mar 08 10:04:39 Z 2012 | post6338 | topc4338 |
Minor discrepancy in distributed--calculated inferred data (collabnet topic id: topc2649)
| Title | Content | Created By | Date Created | ID | Topic ID |
|---|---|---|---|---|---|
| Minor discrepancy in distributed/calculated inferred data | Hi Is it possible to explain why an 'out of the box' classify in release 1.3.2, with the following path settings: Input & Edit: classifier user dev path Output: classifier user classifier path Results in an (albeit tiny) change to the distributed classified data? Specifically, 91927006 | Allergic rhinitis due to tree pollens (disorder) has one stated defining property: 42752001|Due to (attribute)|=418943003|Allergic reaction to tree pollen (disorder)| changed to 42752001|Due to (attribute)|=418364006|Allergic reaction to pollen (disorder)| Thanks Ed Cheetham | edcheetham | Thu Sep 16 09:58:27 Z 2010 | post3253 | topc2649 |
| Re: Minor discrepancy in distributed/calculated inferred data | Hi Ed The IHTSDO Workbench GuideBook August 2010 page 183-4 notes this 'issue' as a spurious return of a pair of added/dropped roles. Our early testing here (please note - not disciplined testing at this stage!) revealed a similar issue. On the first 'out of the box' classify we got a return of 12 added roles and 18 dropped. 2nd run we got 12/12 and then 3rd were were 'back to tors' so to speak. Iimplicated concepts/roles were all procedures. I wonder if this is allied in some way with role grouping between distributed/inferred? If you're interested in exploring further I will reload the bundle and see if I can replicate and send you a screen shot. best regards Donna | dtruran | Mon Nov 29 00:06:27 Z 2010 | post3484 | topc2649 |
| Re: Minor discrepancy in distributed/calculated inferred data | Thanks for responding Donna Interesting it's mentioned in the documentation. I have the ? older documentation distributed with v.1.3.2, and this doesn't seem to have the section you describe. Is the August 2010 version on collabnet somewhere? I guess I just anticipate being asked the same question I have raised at some point. Identifying the behaviour as 'spurious' is a start - it would be reasonable to push a bit harder to identify the background to the spurious-ness, and establish whether and why it's truly isolated or indicates other potential idiosyncrasies/inconsistencies. The tentative nature of my original enquiry was because I wouldn't want anyone spending time investigating an 'issue' resulting from me doing something silly in the first place. If you have a similar experience with different added/dropped roles, then I think it is worth digging deeper and would value any further input you can provide. Kind regards Ed | edcheetham | Mon Nov 29 13:04:49 Z 2010 | post3486 | topc2649 |
| Re: Minor discrepancy in distributed/calculated inferred data | Ed I understand and share your tentativeness. It's early and we too are still exploring and detemining whether the discrepancy is caused by, or merely correlated with, something we're doing. I agree that it is probably worth chasing down.... The problem seems to be 'stable' and replicates with only the same concepts and gives the same returns, so I'm tempted to conclude that it is isolated and not a profound problem .... but perhaps we safely say that it is a bug and not a feature :-) Let me do some further digging and I'll get back to you. Cheers Donna | dtruran | Mon Nov 29 18:24:04 Z 2010 | post3487 | topc2649 |
, multiple selections available,
Copyright © 2025, SNOMED International