Units, Quantities, etc
Graham, I'm trying to make sense of this discussion around computability -- what are the kinds of things that one wants to compute with these kinds of countable things? michael On 18/03/12 10:57 PM, Grahame Grieve grahame at healthintersections.com.au wrote: Are discrete units only encountered in administrative directives? Do you prohibit people from making observations or measurements that include discrete units such as puffs, tablets, patches, vials, strips etc? why? HL7 does because we claim that you have to have UCUM codes so the data can be computable. If people simply want to exchange it in a structured but non-computable fashion... they can go to hell. And as for computable: we insist on a ucum code, and then say that for these discrete unit kind of things, well, you just put 1 for countable units, and then put the effective unit somewhere else - somewhere that no one can actually pull off in practice - because this is more computable. Huh? We do not make sense on this. So much for HL7... what's openEHR's excuse? Grahame On Sun, Mar 18, 2012 at 11:18 PM, Thomas Beale thomas.beale at oceaninformatics.com wrote: As Grahame mentioned on an earlier post, the question of units is thorny. Although we technical people would like to mandate UCUM or some other well-designed computable syntax, on its own, it won't work. There seem to be two reasons for this: it doesn't take care of the need for a displayable form of units, e.g. the computable form 'mcg' or 'ug', where as the displayable is '?g' (Greek mu followed by 'g') it doesn't take care of 'units' like puffs, tablets, patches, vials, strips, and other discrete delivery units it doesn't take care of discrete delivery units per time, e.g. '2 puffs / hour' Grahame and others have already done a lot of thinking on this here - there are a lot of excellent examples from Linda Bird on the Singapore programme. The more I think about the last two above, the more I think it is not about quantities per se but about an administration directive (how the patient should take something). Trying to make Quantity do that kind of stuff doesn't make sense to me - there is obviously a Quantity to indicate the dose in scientific form, but another data element may be needed to indicate how (in what discrete measures) to take the medication. I would therefore expect a distinct data element in the Medication Cluster archetype rather than a re-engineered Quantity type to deal with these last two. For the first one - displayable v computable, we will need a CR to change DV_QUANTITY, and make it work like the FHIR Quantity - i.e. have a second units field. Some of my earlier thoughts are actually on the above wiki page - the concept of a DiscretisedQuantity type inheriting from Quantity, which I think is also a reasonable alternative. what do others think? - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr .org -- - http://www.healthintersections.com.au / grahame at healthintersections.com.au / +61 411 867 065 ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr. org
Units, Quantities, etc
Hi Linda, I think your first example demonstrates why tablet is not a Unit -- I could equally say: 2 Mountains of Paracetamol 500 mg + Codeine Phosphate 15mg Mountains is therapeutically equivalent to 1 Mountain of Paracetamol 1g + Codeine Phosphate 30 mg Mountains Really what I am saying here is: 2 of Paracetamol 500 mg + Codeine Phosphate 15mg Tablet is therapeutically equivalent to 1 of Paracetamol 1g + Codeine Phosphate 30 mg Tablet In your next example, both orders are for 500mg of Amoxicllin in capsule form but the second case also says 1 capsule and carries with it a business rule that says you cannot convert this. However, it still doesn't change the therapeutically equivalent relation. That is, therapeutically equivalence should be treated separately from can be substituted for when dispensing. michael From: linda at mybirdfamily.commailto:linda at mybirdfamily.com linda at mybirdfamily.commailto:li...@mybirdfamily.com Reply-To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.org Date: Mon, 19 Mar 2012 14:56:39 +1100 To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.org Subject: RE: Units, Quantities, etc Ok ... can't resist replying ... Doesn't 'computability' depend on having clearly defined rules on how the UOMs relate to each other? Yes, UCUM provides this - however I don't understand why (in the context of a national program), we would exclude another terminology-based knowledge source (e.g. a SNOMED CT extension) providing these computational rules. If, for example, we referred to 2 tablets of Paracetamol 500 mg + Codeine Phosphate 15 mg Tablet, and we have a knowledge base that tells us that each of these tablets has 500 mg of Paracetamol and 15 mg of Codeine Phosphate, then we can compute that: 2 tablets of Paracetamol 500 mg + Codeine Phosphate 15mg Tablet is therapeutically equivalent to 1 tablet of Paracetamol 1g + Codeine Phosphate 30 mg Tablet This is just one of many 'computations' which are possible with an additional knowledge base that is very useful for decision-support purposes. Clinicians may order 500 mg of Amoxicillin Capsules, or 1 capsule of Amoxicllin 500 mg Capsule ... and these actually mean different things (the former could either mean 1 x 500 mg capsule, 2 x 250 mg capsules, etc; while the later specifically means 1 x 500 mg capsule). In the case of simple dosing, clinicians would expect to see only 2 fields - dose_value and dose_units, irrespective of whether the units is mg or capsules ... with the knowledge base determining the 'computability' rules. Regards, Linda. ___ Dr Linda Bird Information Architect Ph: 0411 274 870 Original Message Subject: Re: Units, Quantities, etc From: Grahame Grieve grahame at healthintersections.com.aumailto:grah...@healthintersections.com.au Date: Mon, March 19, 2012 12:15 pm To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.org for me, conversion between different units that are comparable. You should ask Tom what else he thinks it yields up. I'd be interested. Grahame On Mon, Mar 19, 2012 at 11:06 AM, Michael.Lawley at csiro.aumailto:Michael.Lawley at csiro.au wrote: Graham, I'm trying to make sense of this discussion around computability -- what are the kinds of things that one wants to compute with these kinds of countable things? michael On 18/03/12 10:57 PM, Grahame Grieve grahame at healthintersections.com.aumailto:grahame at healthintersections.com.au wrote: Are discrete units only encountered in administrative directives? Do you prohibit people from making observations or measurements that include discrete units such as puffs, tablets, patches, vials, strips etc? why? HL7 does because we claim that you have to have UCUM codes so the data can be computable. If people simply want to exchange it in a structured but non-computable fashion... they can go to hell. And as for computable: we insist on a ucum code, and then say that for these discrete unit kind of things, well, you just put 1 for countable units, and then put the effective unit somewhere else - somewhere that no one can actually pull off in practice - because this is more computable. Huh? We do not make sense on this. So much for HL7... what's openEHR's excuse? Grahame On Sun, Mar 18, 2012 at 11:18 PM, Thomas Beale thomas.beale at oceaninformatics.commailto:thomas.beale at oceaninformatics.com wrote: As Grahame mentioned on an earlier post, the question of units is thorny. Although we technical people would like to mandate UCUM or some other well-designed computable syntax, on its own, it won't work. There seem to be two reasons for this:
Units, Quantities, etc
Well I'm still stuck trying to understand what you mean by 'computable'. And, no, a clinician cannot prescribe (just) 2 tablets -- I cannot compare that with 500 mg unless I know how much is in each tablet. Once you've told me how much is in each tablet, then (from a computability perspective), I may as well have just said 2 units. michael From: linda at mybirdfamily.commailto:linda at mybirdfamily.com linda at mybirdfamily.commailto:li...@mybirdfamily.com Reply-To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.org Date: Mon, 19 Mar 2012 16:26:31 +1100 To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.org Subject: RE: Units, Quantities, etc Sorry Michael - I don't follow your reasoning. In clinical practice, a clinician may either order a dose of '2 tablets' or alternatively '500 mg'. I would argue that these are both equally 'computable', given the appropriate knowledge base. Regards, Linda. ___ Dr Linda Bird Information Architect Ph: 0411 274 870 Original Message Subject: Re: Units, Quantities, etc From: Michael.Lawley at csiro.aumailto:michael.law...@csiro.au Date: Mon, March 19, 2012 3:03 pm To: openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.org Hi Linda, I think your first example demonstrates why tablet is not a Unit -- I could equally say: 2 Mountains of Paracetamol 500 mg + Codeine Phosphate 15mg Mountains is therapeutically equivalent to 1 Mountain of Paracetamol 1g + Codeine Phosphate 30 mg Mountains Really what I am saying here is: 2 of Paracetamol 500 mg + Codeine Phosphate 15mg Tablet is therapeutically equivalent to 1 of Paracetamol 1g + Codeine Phosphate 30 mg Tablet In your next example, both orders are for 500mg of Amoxicllin in capsule form but the second case also says 1 capsule and carries with it a business rule that says you cannot convert this. However, it still doesn't change the therapeutically equivalent relation. That is, therapeutically equivalence should be treated separately from can be substituted for when dispensing. michael From: linda at mybirdfamily.commailto:linda at mybirdfamily.commailto:linda at mybirdfamily.com linda at mybirdfamily.commailto:linda at mybirdfamily.commailto:li...@mybirdfamily.com Reply-To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.org Date: Mon, 19 Mar 2012 14:56:39 +1100 To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.org Subject: RE: Units, Quantities, etc Ok ... can't resist replying ... Doesn't 'computability' depend on having clearly defined rules on how the UOMs relate to each other? Yes, UCUM provides this - however I don't understand why (in the context of a national program), we would exclude another terminology-based knowledge source (e.g. a SNOMED CT extension) providing these computational rules. If, for example, we referred to 2 tablets of Paracetamol 500 mg + Codeine Phosphate 15 mg Tablet, and we have a knowledge base that tells us that each of these tablets has 500 mg of Paracetamol and 15 mg of Codeine Phosphate, then we can compute that: 2 tablets of Paracetamol 500 mg + Codeine Phosphate 15mg Tablet is therapeutically equivalent to 1 tablet of Paracetamol 1g + Codeine Phosphate 30 mg Tablet This is just one of many 'computations' which are possible with an additional knowledge base that is very useful for decision-support purposes. Clinicians may order 500 mg of Amoxicillin Capsules, or 1 capsule of Amoxicllin 500 mg Capsule ... and these actually mean different things (the former could either mean 1 x 500 mg capsule, 2 x 250 mg capsules, etc; while the later specifically means 1 x 500 mg capsule). In the case of simple dosing, clinicians would expect to see only 2 fields - dose_value and dose_units, irrespective of whether the units is mg or capsules ... with the knowledge base determining the 'computability' rules. Regards, Linda. ___ Dr Linda Bird Information Architect Ph: 0411 274 870 Original Message Subject: Re: Units, Quantities, etc From: Grahame Grieve grahame at healthintersections.com.aumailto:grahame at healthintersections.com.aumailto:grah...@healthintersections.com.au Date: Mon, March 19, 2012 12:15 pm To: For openEHR technical discussions openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.orgmailto:openehr-technical at lists.openehr.org for me, conversion between
openEHR artefact namespace identifiers
Note that in the SNOMED case, there are two identifiers in play: the concept identifier (which contains the namespace ID) and a module identifier. The idea is that ye namespace in the concept identifier will remain fixed and thus indicate the entity that originally introduced the concept, while the moduleId used associated with the defining entries in the release files changes to indicate the entity currently maintaining that concept. michael From: Ian McNicoll Ian.McNicoll at oceaninformatics.commailto:ian.mcnic...@oceaninformatics.com Reply-To: For openEHR technical discussions openehr-technical at openehr.orgmailto:openehr-technical at openehr.org Date: Wed, 6 Apr 2011 01:51:05 +1000 To: For openEHR technical discussions openehr-technical at openehr.orgmailto:openehr-technical at openehr.org Subject: openEHR artefact namespace identifiers Hi, About a year ago Thomas published a draft of some detailed artefact identification proposals at http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf to help with the rapidly approaching scenario of having to cope with similarly named artefacts being published by different authorities. We are starting to see this scenario emerging in real-world projects and whilst potential collisions can be managed informally for now, we will need a formal mechanism before long. I would like to raise one aspect which I think might need re-thought on the basis of recent IHTSDO proposal for SNOMED covering the same ground. In the pdf Thomas says When an archetype is moved from its original PO (e.g. a local health authority, or a specialist peak body) to a more central authoring domain (e.g. a national library, openEHR.org) its namespace will be changed to the new domain, as part of the review and handover process. The archetype's semantic definition may or may not change. In order for tools to know that an archetype was not created new locally, but was moved from another PO, an explicit reference statement can be made in the archetype in the description section of an archetype as follows: id_history = ?se.skl.epj::openEHR-EHR-EVALUATION.problem.v1? The IHTSDO proposals cover the same scenario i.e a SNOMED code originally authored in one namespace subsequently being managed in a new namespace. A good example might be a SNOMED term which is originally used t a national level but is then adopted internationally. They suggest that the term keeps its original authored namespace, and it is the namespace of the managing entity that changes, arguing that this is much less disruptive to systems that are using the term concerned. I think we should consider adopting the same approach for openEHR archetypes, as otherwise the formal identifier of an archetype will change if a locally developed archetype becomes promoted to international use, a relatively common occurrence. We would then need to record the current publisher so that the agency with current responsibility could be identified current_publisher = ?se.skl.epj? Thoughts would be welcome as I think we need to start making these (or alternative) specifications formal to enable tooling and application support to go ahead. Ian Dr Ian McNicoll office +44 (0)1536 414994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.commailto:ian.mcnicoll at oceaninformatics.com Clinical analyst, Ocean Informatics, UK openEHR Clinical Knowledge Editor www.openehr.org/knowledgehttp://www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.orghttp://www.phcsg.org
constraint binding error
Indeed, in Australia, it would be ICD-10-AM but the version would correspond to the particular Edition you're using. Hence my example URI still included the string SNOMED so that one knows how to interpret the v=, s=, m= elements. Clearly every standard terminology is going to have it's own mechanisms for indicating versions, etc. But in this instance, my real point was that SCTIDs need to be used rather than terms. michael On 21/02/11 2:14 PM, pablo pazos pazospablo at hotmail.com wrote: Hi Michael, Not every terminology version is a date. In ICD 10, the version is 10. I think the version to be a valid date is not a problem here.
IHTSDO meeting - term binding presentation available
Yes, the workflow stuff is just a tool feature. The RF2 spec is merely a file format and the spec has nothing to say about how such files may/should be generated. Regarding the clinical metadata elements you mention, these are not defined as part of RF2, but it should be possible to represent them using RF2 as it was designed to be an extensible format. michael Dr Michael Lawley Principal Research Scientist The Australia e-Health Research Centre http://aehrc.com/ +61 7 3253 3609; 0432 832 067 From: openehr-technical-bounces at chime.ucl.ac.uk [openehr-technical-bounces at chime.ucl.ac.uk] On Behalf Of Ian McNicoll [ian.mcnic...@oceaninformatics.com] Sent: Thursday, 6 May 2010 11:16 PM To: For openEHR technical discussions Cc: openehr-clinical at openehr.org; openehr-clinical at chime.ucl.ac.uk; openehr-technical at openehr.org Subject: Re: IHTSDO meeting - term binding presentation available Thanks Michael, Can I ask if the workflow/process elements of the Workbench are regarded as separate from the Refset 2 specifications, or within other offical IHTSDO specs? Or is this just intended as a local feature of the workbench? Although the Refset2 sepcifications define a greate deal of 'metadata', as far as I can tell , other than Refset name, this is almost wholly technical in nature and clinical metadata elements e.g use, misuse, purpose, authoring details are not defined - is this correct? Ian Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.commailto:ian.mcnicoll at oceaninformatics.com ian at mcmi.co.ukmailto:ian at mcmi.co.uk Clinical Analyst Ocean Informatics openEHR Archetype Editorial Group Member BCS Primary Health Care SG Group www.phcsg.orghttp://www.phcsg.org / BCS Health Scotland On 6 May 2010 13:22, Michael.Lawley at csiro.au wrote: I would add to Eric's point 3 that (based on the content of an IHTSDO webinar) the workflow/process implemented in the IHTSDO workbench involves an explicit manual approval step for every item in the generated static refset. I don't know how/if there is any special support for dealing with re-generating the refset based on a new SNOMED release or a modified set of specification queries. m Dr Michael Lawley Principal Research Scientist The Australia e-Health Research Centre http://aehrc.com/ +61 7 3253 3609; 0432 832 067 From: openehr-technical-bounces at chime.ucl.ac.ukmailto:openehr-technical-bounces at chime.ucl.ac.uk [openehr-technical-bounces at chime.ucl.ac.ukmailto:openehr-technical-bounces at chime.ucl.ac.uk] On Behalf Of Eric Browne [eric.browne at montagesystems.com.aumailto:eric.bro...@montagesystems.com.au] Sent: Thursday, 6 May 2010 9:20 PM To: For openEHR clinical discussions Cc: For openEHR clinical discussions; Openehr-Technical Subject: Re: IHTSDO meeting - term binding presentation available Hi Sebastian, If I can give my own perspective on this, having been peripherally involved for some time.. 1. Unfortunately, the IHTSDO (www.ihtsdo.orghttp://www.ihtsdo.org), who is responsible for the ongoing management and development of SNOMED CT, is still a somewhat closed and traditional standards development organisation. It has no publicly accessible wiki of resources ? la openEHR. It does, however, have a substantial community of individuals from member countries and affiliate organisations and several collaborative websites and mailing lists where ideas, contributions, new specifications etc. are documented and evolve. I would guess that the majority of participants are either active in other standards development organisations, or staff/affiliates of member nation health informatics programs such as the UK's NHS Connecting for Health Program, Canada's Infoway, Australia's National E-Health Transition Authority, etc. 2. For many years prior to IHTSDO taking over SNOMED CT from the College of American Pathologists, SNOMED CT embraced a mechanism and format for producing subsets of SNOMED CT. About 18 months ago, proposals for a new SNOMED release format and a new Reference Set format (to replace the old subset mechanism) emerged and evolved. These two proposals morphed into a single umbrella specification called Release Format 2, which has now reached Draft for Trial Use status within the IHTSDO. One of the specification documents covers Reference Set formats and is available in part 2 of RF2 at: http://www.ihtsdo.org/publications/draft-for-review-and-trial-use/ . This draft specification includes support for language refsets, which may be of particular interest to you. Access to the collaborative space where these documents are made available is described at: http://www.ihtsdo.org/about-ihtsdo/collaborative-space/ . 3. To my knowledge there is no formal IHTSDO proposal for a query language to express Refset
IHTSDO meeting - term binding presentation available
I would add to Eric's point 3 that (based on the content of an IHTSDO webinar) the workflow/process implemented in the IHTSDO workbench involves an explicit manual approval step for every item in the generated static refset. I don't know how/if there is any special support for dealing with re-generating the refset based on a new SNOMED release or a modified set of specification queries. m Dr Michael Lawley Principal Research Scientist The Australia e-Health Research Centre http://aehrc.com/ +61 7 3253 3609; 0432 832 067 From: openehr-technical-bounces at chime.ucl.ac.uk [openehr-technical-bounces at chime.ucl.ac.uk] On Behalf Of Eric Browne [eric.bro...@montagesystems.com.au] Sent: Thursday, 6 May 2010 9:20 PM To: For openEHR clinical discussions Cc: For openEHR clinical discussions; Openehr-Technical Subject: Re: IHTSDO meeting - term binding presentation available Hi Sebastian, If I can give my own perspective on this, having been peripherally involved for some time.. 1. Unfortunately, the IHTSDO (www.ihtsdo.org), who is responsible for the ongoing management and development of SNOMED CT, is still a somewhat closed and traditional standards development organisation. It has no publicly accessible wiki of resources ? la openEHR. It does, however, have a substantial community of individuals from member countries and affiliate organisations and several collaborative websites and mailing lists where ideas, contributions, new specifications etc. are documented and evolve. I would guess that the majority of participants are either active in other standards development organisations, or staff/affiliates of member nation health informatics programs such as the UK's NHS Connecting for Health Program, Canada's Infoway, Australia's National E-Health Transition Authority, etc. 2. For many years prior to IHTSDO taking over SNOMED CT from the College of American Pathologists, SNOMED CT embraced a mechanism and format for producing subsets of SNOMED CT. About 18 months ago, proposals for a new SNOMED release format and a new Reference Set format (to replace the old subset mechanism) emerged and evolved. These two proposals morphed into a single umbrella specification called Release Format 2, which has now reached Draft for Trial Use status within the IHTSDO. One of the specification documents covers Reference Set formats and is available in part 2 of RF2 at: http://www.ihtsdo.org/publications/draft-for-review-and-trial-use/ . This draft specification includes support for language refsets, which may be of particular interest to you. Access to the collaborative space where these documents are made available is described at: http://www.ihtsdo.org/about-ihtsdo/collaborative-space/ . 3. To my knowledge there is no formal IHTSDO proposal for a query language to express Refset membership specifications. However, the IHTSDO Terminology Workbench does incorporate quite a sophisticated mechanism for building refsets using an underlying ( and evolving) query-based expression language. Note: these refsets do not necessarily need to be specific to SNOMED. The refset specifications, however, are currently designed to construct static files for distribution alongside the SNOMED core and national extension files, rather than for producing dynamically evaluated termsets for local needs, as might be supported for openEHR templates, say. eric On 2010-05-06, at 5:48 PM, Sebastian Garde wrote: Hi Thomas, do you know if there is a formal way of how RefSets (=the resulting Snomed CT codes etc.) and the RefSet query (=the query on Snomed CT to get to the RefSet) are expressed and shared? Similar to what is described here but based on RefSets: http://www.openehr.org/wiki/display/term/Ocean+Terminology+Query+Language+%28TQL%29 I agree that RefSets are a good way forward, but they need to be available, reusable and sharable, etc. Sebastian Thomas Beale wrote: I attended the IHTSDO meeting just finished in Copenhagen. Things look pretty good for where SNOMED CT is going generally - the RF2 technical infrastructure seems relatively well designed. There is a lot of activity in content modeling, the IHTSDO workbench and many other areas relevant to openEHR. Converely, I believe openEHR will be very important to make SNOMED CT work in many places, since it will be via archetypes, templates and associated ref sets that information systems will be able to connect to terminology in a disciplined way. I believe that ref sets are the future of SNOMED CT (and any terminology for that matter) in use in real systems. I was asked to present a view from openEHR about 'terminology binding', i.e. connecting terminology and information models. My presentation is on this page http://www.openehr.org/wiki/display/term/Terminology+Binding or see the following direct links: ? PDF -
Term bindings in archetypes and templates
Hi Mikael, You may be interested in our mapping tool, Snapper, which is designed to tackle this problem for mapping to (not from) SNOMED CT. It provides extensive support for mapping to post-coordinated expressions where single-concept maps are not possible and can be used to create unofficial extensions to SNOMED CT. More details and a short screen-cast are on our website http://aehrc.com/snapper Cheers, michael -- Dr Michael Lawley Principal Research Scientist The Australia e-Health Research Centre http://aehrc.com/ +61 7 3253 3609; 0432 832 067 Ein Fl?gel und einen Schnabel machen kein Vogel On 11/03/10 9:49 AM, Mikael Nystr?m mikael.nystrom at liu.se wrote: Thomas Beale wrote: On 10/03/2010 22:16, Mikael Nystr?m wrote: I belong to a group that, except for openEHR related research, also do research about terminology systems and terminology systems mapping. During mapping from one terminology system to another terminology system is it quite common to be unable to map properly, because the two terminology systems have divided the domain in different ways. This problem appears even when mapping to SNOMED CT, which have a broad coverage and a concept model allowing a broad set of relationships. My view is that the same problem will appear when finalized archetypes are bound to existing terminology systems. it will certainly appear. The question is: for those archetype nodes that it is useful to bind to terminology (likely to be 10% or less), how close is the match? For example, in labs, it should be nearly spot on. For anatomy, it should be pretty close. For diseases, the disease concept in an archetype will assume that it is coded in the first place by terminology, so the only problem there is mapping problems from ICD to SCT etc. I think we need to look at the actual size of the concrete problem, not its theoretical worst case. I agree that we have to wait and see how much problems we will get. That was also my reason to reply to Sebastian's e-mail which told that there is no problem to add terminology bindings after the archetypes are finalized. However, I didn't refer to theoretical worst case. I referred to actual problems that have appeared for us during both our research work and in our national SNOMED CT project in Sweden. Greetings, Mikael ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
