Postulate: DV_QUANTITY should be modelled with fewest possible units
Could assertions/rules be used for this kind of profiles? 2014-11-13 22:03 GMT+01:00 Thomas Beale : > On 13/11/2014 20:34, Bakke, Silje Ljosland wrote: > > The original context for this discussion was this archetype: > http://arketyper.no/ckm/#showArchetype_1078.36.25 (default archetype > language for this CKM is Norwegian, but it can be changed manually) > > Being an all-metric country since the 1800s, we've removed lbs as a possible > unit, but added g (gram) for weighing infants. > > > There is something I have been thinking about for a while, which is whether > we need some kind of 'profiles' in archetypes, that can be used select or > deselect alternative constraints. An 'alternative' in an archetype is > technically > > an alternative object constraint under a single-valued attribute; example: a > DV_QUANTITY and a DV_COUNT as siblings under ELEMENT.value representing > 'amount of tobacco' > any optional object under a container attribute, typically with other > siblings > any branch of a tuple (ADL 2 speak) or branch of C_DV_QUANTITY - this is the > units example > > So I have been thinking whether we need something like a profile section, > with named profiles, pointing to the paths of things in (or not in) that > profile. We could imagine profiles like: > > profiles = < > ["metric"] = > ["system international"] = > ["british imperial"] = <...> > ["us imperial"] = <...> >> > > Now the question is whether this just applies to units, or whether it's more > global. For example, could there be an argument to create profiles for > 'general practice', 'icu', 'aged care'? Consider the example of the BP > archetype. It contains 'systolic pressure', 'diastolic pressure', 'pulse > pressure' and 'mean arterial pressure'. Now the last two are only used in > anaesthesiology and specific instruments (from memory); one could imagine > some profiles that would select out pulse pressure for just > 'anaesthesiology'. > > Right now, this selection occurs by people specialising archetypes, and > ultimately making templates, and along they way, getting rid of things they > don't want, and keeping what they do. But there's no way you can run a query > over an archetype library and filter it on some specialty, or even 'metric'. > > But there are many other reasons for specialising and removing / keeping > elements as well - geographical, legislative, anything... > > So for now this remains just an idea - we would need some input from > clinical modellers to know whether it's a useful one or not. > > - thomas > > > ___ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
Postulate: DV_QUANTITY should be modelled with fewest possible units
The original context for this discussion was this archetype: http://arketyper.no/ckm/#showArchetype_1078.36.25 (default archetype language for this CKM is Norwegian, but it can be changed manually) Being an all-metric country since the 1800s, we've removed lbs as a possible unit, but added g (gram) for weighing infants. Regards, Silje > -Original Message- > From: openEHR-technical [mailto:openehr-technical- > bounces at lists.openehr.org] On Behalf Of Diego Bosc? > Sent: Thursday, November 13, 2014 9:23 PM > To: For openEHR technical discussions > Cc: openehr-clinical at lists.openehr.org > Subject: Re: Postulate: DV_QUANTITY should be modelled with fewest > possible units > > As mentioned on twitter, I agree with that postulate for templates, but not > general archetypes :) > > 2014-11-13 21:07 GMT+01:00 Bj?rn N?ss : > > I want to try out a postulate regarding modelling of datavalues, and > > more specific DV_QUANTITY. > > > > > > > > The postulate is: > > > > > > > > Postulate 1: A data type of DV_QUANTITY should be modelled with fewest > > possible units! > > > > > > > > Reason behind this is to make queries and reasoning over the values easy. > > This makes it both faster and safer building sustainable software and > > systems using these values. > > > > I also think that converting between i.e. grams and kilos should be > > done in the client (user interface / integration engine/ etc.). > > > > > > > > What do you think? > > > > > > > > > > > > > > > > > > > > Vennlig hilsen > > Bj?rn N?ss > > Product Owner > > DIPS ASA > > > > Mobil +47 93 43 29 10 > > > > > > > > > > ___ > > openEHR-technical mailing list > > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.open > > ehr.org > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr- > technical_lists.openehr.org
Postulate: DV_QUANTITY should be modelled with fewest possible units
As mentioned on twitter, I agree with that postulate for templates, but not general archetypes :) 2014-11-13 21:07 GMT+01:00 Bj?rn N?ss : > I want to try out a postulate regarding modelling of datavalues, and more > specific DV_QUANTITY. > > > > The postulate is: > > > > Postulate 1: A data type of DV_QUANTITY should be modelled with fewest > possible units! > > > > Reason behind this is to make queries and reasoning over the values easy. > This makes it both faster and safer building sustainable software and > systems using these values. > > I also think that converting between i.e. grams and kilos should be done in > the client (user interface / integration engine/ etc.). > > > > What do you think? > > > > > > > > > > Vennlig hilsen > Bj?rn N?ss > Product Owner > DIPS ASA > > Mobil +47 93 43 29 10 > > > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Postulate: DV_QUANTITY should be modelled with fewest possible units
Hi Bj?rn, IMO when you have complex unit processing, a lookup service for UCUM might be needed. UCUM contains multipliers and correspondences between different unit systems, check this: http://unitsofmeasure.org/ucum-essence.xml Using this, a constraint on archetypes might not be needed. What do you think? -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com From: b...@dips.no To: openehr-technical at lists.openehr.org; openehr-clinical at lists.openehr.org Subject: Postulate: DV_QUANTITY should be modelled with fewest possible units Date: Thu, 13 Nov 2014 20:07:00 + I want to try out a postulate regarding modelling of datavalues, and more specific DV_QUANTITY. The postulate is: Postulate 1: A data type of DV_QUANTITY should be modelled with fewest possible units! Reason behind this is to make queries and reasoning over the values easy. This makes it both faster and safer building sustainable software and systems using these values. I also think that converting between i.e. grams and kilos should be done in the client (user interface / integration engine/ etc.). What do you think? Vennlig hilsen Bj?rn N?ss Product Owner DIPS ASA Mobil +47 93 43 29 10 ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/8ab4298a/attachment.html>
Postulate: DV_QUANTITY should be modelled with fewest possible units
On 13/11/2014 20:34, Bakke, Silje Ljosland wrote: > The original context for this discussion was this archetype: > http://arketyper.no/ckm/#showArchetype_1078.36.25 (default archetype language > for this CKM is Norwegian, but it can be changed manually) > > Being an all-metric country since the 1800s, we've removed lbs as a possible > unit, but added g (gram) for weighing infants. > There is something I have been thinking about for a while, which is whether we need some kind of 'profiles' in archetypes, that can be used select or deselect alternative constraints. An 'alternative' in an archetype is technically 1. an alternative object constraint under a single-valued attribute; example: a DV_QUANTITY and a DV_COUNT as siblings under ELEMENT.value representing 'amount of tobacco' 2. any optional object under a container attribute, typically with other siblings 3. any branch of a tuple (ADL 2 speak) or branch of C_DV_QUANTITY - this is the units example So I have been thinking whether we need something like a profile section, with named profiles, pointing to the paths of things in (or not in) that profile. We could imagine profiles like: profiles = < ["metric"] = ["system international"] = ["british imperial"] = <...> ["us imperial"] = <...> > Now the question is whether this just applies to units, or whether it's more global. For example, could there be an argument to create profiles for 'general practice', 'icu', 'aged care'? Consider the example of the BP archetype. It contains 'systolic pressure', 'diastolic pressure', 'pulse pressure' and 'mean arterial pressure'. Now the last two are only used in anaesthesiology and specific instruments (from memory); one could imagine some profiles that would select out pulse pressure for just 'anaesthesiology'. Right now, this selection occurs by people specialising archetypes, and ultimately making templates, and along they way, getting rid of things they don't want, and keeping what they do. But there's no way you can run a query over an archetype library and filter it on some specialty, or even 'metric'. But there are many other reasons for specialising and removing / keeping elements as well - geographical, legislative, anything... So for now this remains just an idea - we would need some input from clinical modellers to know whether it's a useful one or not. - thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/62c53624/attachment.html>
Archetypes - new meta-data elements for 3rd party copyrights?
you do not need to pay, but the licensing requirements are quite specific about what kind of attribution is required. Grahame On Thu, Nov 13, 2014 at 8:19 PM, Stefan Sauermann < sauermann at technikum-wien.at> wrote: > Hello! > We are using LOINC in Austria for coding lab results on a national scale. > As far as I know nobody needs to pay anything to Regenstrief to do so. > > I am not aware of any "must mention Regenstrief" requirements, but I may > miss something. > Greetings from Vienna, > Stefan > > Stefan Sauermann > > Program Director > Biomedical Engineering Sciences (Master) > > University of Applied Sciences Technikum Wien > Hoechstaedtplatz 5, 1200 Vienna, Austria > P: +43 1 333 40 77 - 988 > M: +43 664 6192555 > E: stefan.sauermann at technikum-wien.at > > I: www.technikum-wien.at/mbe > I: www.technikum-wien.at/ibmt > I: www.healthy-interoperability.at > > Am 13.11.2014 10:07, schrieb Grahame Grieve: > > my advice from LOINC/regenstrief is that it does apply > > Grahame > > > On Thu, Nov 13, 2014 at 8:01 PM, Thomas Beale < > thomas.beale at oceaninformatics.com> wrote: > >> >> Something that has become clear in CIMI, and will affect openEHR, 13606 >> and most likely any archetype developer is that acknowledgements of 3rd >> party copyrights and trademarks need to be made. The most obvious common >> one is likely to be for SNOMED CT codes in archetype bindings (Stan Huff at >> Intermountain is still working on whether such acknowledgements are needed >> for LOINC codes). However, it could be for anything, e.g. rights to use a >> scale like Barthel or Waterlow. >> >> At the moment there is no dedicated place in the model for this >> particular meta-data. It could just go in 'other_details' but I suspect >> that we need to be more precise than that. Consider for example, the >> openEHR Barthel scale archetype - it currently carries this text in the >> 'Use' section: >> >> Note: >> The Maryland State Medical Society holds the copyright for the Barthel >> Index. It may be used freely for non-commercial purposes with the >> following citation: >> Mahoney FI, Barthel D. ?Functional evaluation: the Barthel Index.? >> Maryland State Med Journal 1965;14:56-61. Used with permission. >> >> Permission is required to modify the Barthel Index or to use it for >> commercial purposes. >> >> This seems less than optimal, and is certainly not going to be reliably >> tool-separable from the main 'Use' content, since the word 'Note:' and the >> placement of this text are purely local choices. >> >> There is another issue here. The acknowledgement text actually included >> in the archetype needs to be minimal, and as far as legally possible not >> contain volatile elements that can change. Therefore, I think the general >> approach needs to be as is typically done with open source licences: not >> including the whole text, but including a reliable URL to the licence text >> either from the issuer (e.g. Creative Commons CC-BY page) or an agreement >> between the publisher and the licensor (e.g. between IHTSDO and CIMI for >> the use of SNOMED CT, and details of that use). >> >> I have updated the meta-data page on the wiki >> <http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Meta-data>to >> indicate what I think is the requirement - see end of the main table. >> >> I am increasingly of the feeling that we need to act on this soon. >> >> - thomas >> >> ___ >> openEHR-clinical mailing list >> openEHR-clinical at lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >> > > > > -- > - > http://www.healthintersections.com.au / grahame at healthintersections.com.au > / +61 411 867 065 > > > ___ > openEHR-clinical mailing listopenEHR-clinical at > lists.openehr.orghttp://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > > > -- - http://www.healthintersections.com.au / grahame at healthintersections.com.au / +61 411 867 065 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/7ceb12ce/attachment.html>
Archetypes - new meta-data elements for 3rd party copyrights?
my advice from LOINC/regenstrief is that it does apply Grahame On Thu, Nov 13, 2014 at 8:01 PM, Thomas Beale < thomas.beale at oceaninformatics.com> wrote: > > Something that has become clear in CIMI, and will affect openEHR, 13606 > and most likely any archetype developer is that acknowledgements of 3rd > party copyrights and trademarks need to be made. The most obvious common > one is likely to be for SNOMED CT codes in archetype bindings (Stan Huff at > Intermountain is still working on whether such acknowledgements are needed > for LOINC codes). However, it could be for anything, e.g. rights to use a > scale like Barthel or Waterlow. > > At the moment there is no dedicated place in the model for this particular > meta-data. It could just go in 'other_details' but I suspect that we need > to be more precise than that. Consider for example, the openEHR Barthel > scale archetype - it currently carries this text in the 'Use' section: > > Note: > The Maryland State Medical Society holds the copyright for the Barthel > Index. It may be used freely for non-commercial purposes with the > following citation: > Mahoney FI, Barthel D. ?Functional evaluation: the Barthel Index.? > Maryland State Med Journal 1965;14:56-61. Used with permission. > > Permission is required to modify the Barthel Index or to use it for > commercial purposes. > > This seems less than optimal, and is certainly not going to be reliably > tool-separable from the main 'Use' content, since the word 'Note:' and the > placement of this text are purely local choices. > > There is another issue here. The acknowledgement text actually included in > the archetype needs to be minimal, and as far as legally possible not > contain volatile elements that can change. Therefore, I think the general > approach needs to be as is typically done with open source licences: not > including the whole text, but including a reliable URL to the licence text > either from the issuer (e.g. Creative Commons CC-BY page) or an agreement > between the publisher and the licensor (e.g. between IHTSDO and CIMI for > the use of SNOMED CT, and details of that use). > > I have updated the meta-data page on the wiki > <http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Meta-data>to > indicate what I think is the requirement - see end of the main table. > > I am increasingly of the feeling that we need to act on this soon. > > - thomas > > ___ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org > -- - http://www.healthintersections.com.au / grahame at healthintersections.com.au / +61 411 867 065 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/08b791f1/attachment.html>
Postulate: DV_QUANTITY should be modelled with fewest possible units
I want to try out a postulate regarding modelling of datavalues, and more specific DV_QUANTITY. The postulate is: Postulate 1: A data type of DV_QUANTITY should be modelled with fewest possible units! Reason behind this is to make queries and reasoning over the values easy. This makes it both faster and safer building sustainable software and systems using these values. I also think that converting between i.e. grams and kilos should be done in the client (user interface / integration engine/ etc.). What do you think? Vennlig hilsen Bj?rn N?ss Product Owner DIPS ASA Mobil +47 93 43 29 10 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/9dd2e268/attachment.html>
Another meta-data requirement from CIMI
On 13/11/2014 18:43, David Moner wrote: > > > 2014-11-13 19:23 GMT+01:00 Thomas Beale > <mailto:thomas.beale at oceaninformatics.com>>: > > On 13/11/2014 16:50, David Moner wrote: >> As you say, this information should be somehow related to the >> "is_generated" flag. But if we consider that once a human user >> reviews the archetype that flag is set to false, then I don't >> find it needed at all. > > ah - but consider the situation in which the generation step is > done multiple times, over a period of time. I was in this > situation with my internal 1.4 => 1.5 (now => 2.0) generator, > where it took some time to get the converter right. And Patrick > Langford is iteratively getting the Intermountain converter right > over a period of some months. > > The ADL WB always looks at that flag to know what to do. If you > right click on an archetype in the left side explorer, and do > 'Edit', the GUI editor (alpha for the moment, but functionally the > same concept as the LinkEHR editor) starts. If the user actually > makes any changes and commits them, the AWB removes the > is_generated flag. Then a later round of import generation can > look at it, and not overwrite this particular archetype, and > instead generate a warning (or it could try to do a merge, or..). > So I think it's needed. > > > Yes, I understand the process. What I tried to propose was that, if we > add that import information section, the generated flag could be part > of it, instead having it as a standalone reserved word in the header > (just an idea to explore). And that's why I also support adding the > import information as a proper, standalone section. > well the problem there is that 'is_generated' can be set for other reasons. E.g. the ADL 1.4 => 2.x converter. This isn't an import, it's a format convert - but the basic need is the same - to know when the generated one becomes the master, due to someone editing it. So at the moment I see 'is_generated' as a distinct thing from importing... - thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/c65a3142/attachment.html>
Another meta-data requirement from CIMI
We can't assume that an approved/published Intermountain model (to say something) automatically becomes a published archetype either. So we have a problem here. Which should be the default life cycle state of an auto-generated archetype? 2014-11-13 19:41 GMT+01:00 Thomas Beale : > On 13/11/2014 18:37, David Moner wrote: > > I don't think so, but maybe we could use the release_candidate state, > instead the draft one that I mentioned. > > > well I think either could be correct, depending on the circumstances. E.g. > the latest openEHR/FHIR joint Adverse reaction archetype might go in at > 'release_candidate', but many other openEHR ones wouldn't. Even archetypes > that are 'published' according to us could easily go in as drafts, since it > may be that CIMI is the first environment where a really wide group of > reviewers looks at it (and inevitably changes it). > > So.. I don't see any clear rules just yet ;-) > > - thomas > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es http://www.linkedin.com/in/davidmoner Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia - 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/41d806b1/attachment.html>
Another meta-data requirement from CIMI
2014-11-13 19:23 GMT+01:00 Thomas Beale : > On 13/11/2014 16:50, David Moner wrote: > > As you say, this information should be somehow related to the > "is_generated" flag. But if we consider that once a human user reviews the > archetype that flag is set to false, then I don't find it needed at all. > > > ah - but consider the situation in which the generation step is done > multiple times, over a period of time. I was in this situation with my > internal 1.4 => 1.5 (now => 2.0) generator, where it took some time to get > the converter right. And Patrick Langford is iteratively getting the > Intermountain converter right over a period of some months. > > The ADL WB always looks at that flag to know what to do. If you right > click on an archetype in the left side explorer, and do 'Edit', the GUI > editor (alpha for the moment, but functionally the same concept as the > LinkEHR editor) starts. If the user actually makes any changes and commits > them, the AWB removes the is_generated flag. Then a later round of import > generation can look at it, and not overwrite this particular archetype, and > instead generate a warning (or it could try to do a merge, or..). So I > think it's needed. > > Yes, I understand the process. What I tried to propose was that, if we add that import information section, the generated flag could be part of it, instead having it as a standalone reserved word in the header (just an idea to explore). And that's why I also support adding the import information as a proper, standalone section. -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es http://www.linkedin.com/in/davidmoner Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia - 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/ca813d0c/attachment-0001.html>
Another meta-data requirement from CIMI
On 13/11/2014 18:48, David Moner wrote: > We can't assume that an approved/published Intermountain model (to say > something) automatically becomes a published archetype either. So we > have a problem here. Which should be the default life cycle state of > an auto-generated archetype? I don't think there is any relationship. I think the lifecycle state for the generated archetype has to be set by some human-input parameter that's agreed beforehand, or it could be reset later in the tool. I don't think this value is guessable by machines. - thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/f174aa4c/attachment.html>
Another meta-data requirement from CIMI
I don't think so, but maybe we could use the release_candidate state, instead the draft one that I mentioned. 2014-11-13 19:32 GMT+01:00 Diego Bosc? : > Could "autogenerated" be a valid lifecycle state? > > 2014-11-13 19:23 GMT+01:00 Thomas Beale >: > > On 13/11/2014 16:50, David Moner wrote: > > > > As you say, this information should be somehow related to the > "is_generated" > > flag. But if we consider that once a human user reviews the archetype > that > > flag is set to false, then I don't find it needed at all. > > > > > > ah - but consider the situation in which the generation step is done > > multiple times, over a period of time. I was in this situation with my > > internal 1.4 => 1.5 (now => 2.0) generator, where it took some time to > get > > the converter right. And Patrick Langford is iteratively getting the > > Intermountain converter right over a period of some months. > > > > The ADL WB always looks at that flag to know what to do. If you right > click > > on an archetype in the left side explorer, and do 'Edit', the GUI editor > > (alpha for the moment, but functionally the same concept as the LinkEHR > > editor) starts. If the user actually makes any changes and commits them, > the > > AWB removes the is_generated flag. Then a later round of import > generation > > can look at it, and not overwrite this particular archetype, and instead > > generate a warning (or it could try to do a merge, or..). So I think it's > > needed. > > > > What we would need instead is to define a good practice that says that > when > > an archetype is built automatically it must be in draft state, pending of > > further validation, as any other draft. > > > > > > well that depends on whether we think an import step always creates a > > 'draft' archetype. It might be that the source model, say an > Intermountain > > CEM is actually in an 'approved' state, and Intermountain (and maybe even > > CIMI) don't intend to do anything furhter with it after import. Although > not > > likely to be the most common case, I don't think we can presuppose that > the > > lifecycle is rigidly restarted because of an import step. > > > > > > In any case, adding the information that you propose about the original > > source or the import method seems very useful. I have the doubt if a new > > metadata section is needed or it could be considered as reference > > information or just as other details. A new section makes it more > traceable > > automatically, as you say. > > > > > > I'm not too worried either way, but more inclined to add new meta-data > > sections if we think we know what they look like, since it reduces > interop > > errors - there's no choice about the property names etc, wheres it's > always > > a risk to hope that everyone will get the other_details section tags > > identical. > > > > - thomas > > > > ___ > > openEHR-technical mailing list > > openEHR-technical at lists.openehr.org > > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es http://www.linkedin.com/in/davidmoner Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia - 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/c29ab281/attachment.html>
Another meta-data requirement from CIMI
Could "autogenerated" be a valid lifecycle state? 2014-11-13 19:23 GMT+01:00 Thomas Beale : > On 13/11/2014 16:50, David Moner wrote: > > As you say, this information should be somehow related to the "is_generated" > flag. But if we consider that once a human user reviews the archetype that > flag is set to false, then I don't find it needed at all. > > > ah - but consider the situation in which the generation step is done > multiple times, over a period of time. I was in this situation with my > internal 1.4 => 1.5 (now => 2.0) generator, where it took some time to get > the converter right. And Patrick Langford is iteratively getting the > Intermountain converter right over a period of some months. > > The ADL WB always looks at that flag to know what to do. If you right click > on an archetype in the left side explorer, and do 'Edit', the GUI editor > (alpha for the moment, but functionally the same concept as the LinkEHR > editor) starts. If the user actually makes any changes and commits them, the > AWB removes the is_generated flag. Then a later round of import generation > can look at it, and not overwrite this particular archetype, and instead > generate a warning (or it could try to do a merge, or..). So I think it's > needed. > > What we would need instead is to define a good practice that says that when > an archetype is built automatically it must be in draft state, pending of > further validation, as any other draft. > > > well that depends on whether we think an import step always creates a > 'draft' archetype. It might be that the source model, say an Intermountain > CEM is actually in an 'approved' state, and Intermountain (and maybe even > CIMI) don't intend to do anything furhter with it after import. Although not > likely to be the most common case, I don't think we can presuppose that the > lifecycle is rigidly restarted because of an import step. > > > In any case, adding the information that you propose about the original > source or the import method seems very useful. I have the doubt if a new > metadata section is needed or it could be considered as reference > information or just as other details. A new section makes it more traceable > automatically, as you say. > > > I'm not too worried either way, but more inclined to add new meta-data > sections if we think we know what they look like, since it reduces interop > errors - there's no choice about the property names etc, wheres it's always > a risk to hope that everyone will get the other_details section tags > identical. > > - thomas > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Another meta-data requirement from CIMI
On 13/11/2014 18:37, David Moner wrote: > I don't think so, but maybe we could use the release_candidate state, > instead the draft one that I mentioned. well I think either could be correct, depending on the circumstances. E.g. the latest openEHR/FHIR joint Adverse reaction archetype might go in at 'release_candidate', but many other openEHR ones wouldn't. Even archetypes that are 'published' according to us could easily go in as drafts, since it may be that CIMI is the first environment where a really wide group of reviewers looks at it (and inevitably changes it). So.. I don't see any clear rules just yet ;-) - thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/11faa05a/attachment.html>
Another meta-data requirement from CIMI
On 13/11/2014 16:50, David Moner wrote: > As you say, this information should be somehow related to the > "is_generated" flag. But if we consider that once a human user reviews > the archetype that flag is set to false, then I don't find it needed > at all. ah - but consider the situation in which the generation step is done multiple times, over a period of time. I was in this situation with my internal 1.4 => 1.5 (now => 2.0) generator, where it took some time to get the converter right. And Patrick Langford is iteratively getting the Intermountain converter right over a period of some months. The ADL WB always looks at that flag to know what to do. If you right click on an archetype in the left side explorer, and do 'Edit', the GUI editor (alpha for the moment, but functionally the same concept as the LinkEHR editor) starts. If the user actually makes any changes and commits them, the AWB removes the is_generated flag. Then a later round of import generation can look at it, and not overwrite this particular archetype, and instead generate a warning (or it could try to do a merge, or..). So I think it's needed. > What we would need instead is to define a good practice that says that > when an archetype is built automatically it must be in draft state, > pending of further validation, as any other draft. well that depends on whether we think an import step always creates a 'draft' archetype. It might be that the source model, say an Intermountain CEM is actually in an 'approved' state, and Intermountain (and maybe even CIMI) don't intend to do anything furhter with it after import. Although not likely to be the most common case, I don't think we can presuppose that the lifecycle is rigidly restarted because of an import step. > > In any case, adding the information that you propose about the > original source or the import method seems very useful. I have the > doubt if a new metadata section is needed or it could be considered as > reference information or just as other details. A new section makes it > more traceable automatically, as you say. > I'm not too worried either way, but more inclined to add new meta-data sections if we think we know what they look like, since it reduces interop errors - there's no choice about the property names etc, wheres it's always a risk to hope that everyone will get the other_details section tags identical. - thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/c474cf97/attachment.html>
Another meta-data requirement from CIMI
As you say, this information should be somehow related to the "is_generated" flag. But if we consider that once a human user reviews the archetype that flag is set to false, then I don't find it needed at all. What we would need instead is to define a good practice that says that when an archetype is built automatically it must be in draft state, pending of further validation, as any other draft. In any case, adding the information that you propose about the original source or the import method seems very useful. I have the doubt if a new metadata section is needed or it could be considered as reference information or just as other details. A new section makes it more traceable automatically, as you say. David 2014-11-13 17:29 GMT+01:00 Thomas Beale : > > In CIMI, there are now some thousands of archetypes, 90% converted from > Intermountain CEMs. We can start converting openEHR archetypes to CIMI form > as well, for contribution to CIMI. To provide traceability, we probably are > going to need a new meta-data item where some information about model > conversion/import can be represented. In the current CIMI generated > archetypes (not the reference ones), it could be information like: > > "converted with IHCModelConverter v3.134.0.78, on 12-10-2014 at > Intermountain Healthcare, UT" > > or > > " converted with ADL Workbench v2.0.5.2345, on 03-11-2014T12:05:00 for > openEHR Foundation" > > or similar, so that conversion errors can be traced to tools, and also to > simply indicate that the archetype was machine converted. Note that there > is already an 'is_generated' flag in an archetype. So that when an > archetype is imported this is True, but later CIMI authors may start > manually modifying it, then it is set to False. That way you can tell if > the archetype is still being imported or not. So the meta-data for this > purpose might be something like: > > import_details = < > original_source = <"Intermountain model xyz avalable at "> > time = <2014-10-12T12:44:00> > method = <"IHCModelConverter v3.134.0.78"> > other_details = < >-- tagged values > > > > thoughts on this? > > - thomas > > ___ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr- > clinical_lists.openehr.org > -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es http://www.linkedin.com/in/davidmoner Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia - 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/b558be78/attachment-0001.html>
Another meta-data requirement from CIMI
In CIMI, there are now some thousands of archetypes, 90% converted from Intermountain CEMs. We can start converting openEHR archetypes to CIMI form as well, for contribution to CIMI. To provide traceability, we probably are going to need a new meta-data item where some information about model conversion/import can be represented. In the current CIMI generated archetypes (not the reference ones), it could be information like: "converted with IHCModelConverter v3.134.0.78, on 12-10-2014 at Intermountain Healthcare, UT" or " converted with ADL Workbench v2.0.5.2345, on 03-11-2014T12:05:00 for openEHR Foundation" or similar, so that conversion errors can be traced to tools, and also to simply indicate that the archetype was machine converted. Note that there is already an 'is_generated' flag in an archetype. So that when an archetype is imported this is True, but later CIMI authors may start manually modifying it, then it is set to False. That way you can tell if the archetype is still being imported or not. So the meta-data for this purpose might be something like: import_details = < original_source = <"Intermountain model xyz avalable at "> time = <2014-10-12T12:44:00> method = <"IHCModelConverter v3.134.0.78"> other_details = < >-- tagged values > thoughts on this? - thomas
openEHR Confluence and Jira - Atlassian on Demand is available to us
Historically Atlassian has provided openEHR Foundation with a 'community licence' to use Confluence and Jira for free, which has been great, and much appreciated. However, the downside has been the system administration side of things, and we have had problems in the past with stability and occasionally with upgrades. It turns out that openEHR qualifies for Atlassian 'open source' status, and they have now approved our use of Atlassian On Demand (AOD) for Jira and Confluence. This would mean that we can move the contents of our Jira and Confluence instances (currently self-hosted) to AOD, and take advantage of their system administration, hosting etc. openEHR now have volunteer sysadmins from Marand, Code24 and DIPS, and in discussion yesterday they all agreed with transitioning to AOD from self-hosted would be preferable in principle. I'm mentioning it here to alert the community of a few things. * there are various 'limitations' in AOD compared to self-hosting, documented here <https://confluence.atlassian.com/display/AOD/Restricted+Functions+in+Atlassian+OnDemand>. These are almost all either server side management functions, which naturally Atlassian will control on their own cloud, and some limitations on themes / customisation. Now many companies use AOD (including we at Ocean and I would imagine many of your own companies and organisations), and noone things about any of these as problems. o the only technical downside on AOD is that the domain name will be openehr.atlassian.net, not something.openehr.org. This is a well known limitation of AOD Confluence and Jira, but I don't believe it's a serious problem for the openEHR community. We will of course install the appropriate Apache redirects from http://www.openehr.org/wiki and http://www.openehr.org/jira * the major upside is near 100% availability and silent upgrading, and easy to manage backups * we get support from Atlassian either way - and their support is extremely good - they always respond in 24h. * we will need to do an upload of backed up content from the current wiki and Jira, and there are of course always some risks with that. o One thing we need to be sure of is that links still work as expected. Quite a few links probably point to http://www.openehr.org/wiki and http://www.openehr.org/jira, and although these will work, it is obviously more efficient if they point directly to the new destination. We'll investigate if there are any issues there. o We also need to see how the user DB will be restored on both Jira and Confluence. * although we are not required to, we should recognise Atlassian (and other major tool providers) on the openEHR website, which we don't actually do on the current site, so we should make some addition to the home page for that. I'll do a test this weekend on the new site. Unless there are strong objections from anyone in the community, I think we will go ahead with this change. If anyone does have objections, or sees a problem with the move, please post on the technical or clinical lists. thanks - thomas beale -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/5eac5f99/attachment.html>
Archetypes - new meta-data elements for 3rd party copyrights?
Maybe in the case of terminologies it could be put in a kind of "terminology metadata" part that we discussed some time ago to correctly identify the different terminology versions. 2014-11-13 11:33 GMT+01:00 Thomas Beale : > On 13/11/2014 10:02, Heather Leslie wrote: >> >> I've had discussions with IHTSDO about needing a formal statement about >> SCT that should be placed in archetypes and this will be identical to that >> which they are currently working on with CIMI. >> >> Regards >> >> Heather > > > The main thing we need to do with this in my view is put most of such > statements online in each user org (CIMI, Intermountain, openEHR etc) and > make the text that is in the archetype itself as short as legally possible. > > Consider that putting the whole (identical) statement for each acknowledged > type of IP in the current CIMI archetypes - 2200 of them - would a) dwarf > the main content in most of those archetypes and b) create a source of > unnecessary updates to archetypes. Consider a licence notice for SNOMED CT > for example. If it mentions 'IHTSDO', it will most likely be out of date in > a year's time if IHTSDO changes its name next year, as was talked about at > the recent meeting in Amsterdam, and that's 2200 archetypes that have to be > put through a revision and reissue process, unnecessarily. > > - thomas > > > ___ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
Archetypes - new meta-data elements for 3rd party copyrights?
Ooops, I take note of that :-)
Tip of the day: In Spanish both licencia (noun) and licenciar (verb) use a
'c'
2014-11-13 10:58 GMT+01:00 Thomas Beale :
>
> Hi David,
>
> licence is taken care of in the model as it is today
> <http://www.openehr.org/wiki/download/attachments/45645905/AOM_archetype_package.png?version=2&modificationDate=1412032298000&api=v2>.
> Note that it is currently spelt in international English, not US English
> ('license', which is only a verb in International English).
>
> - thomas
>
> On 13/11/2014 09:30, David Moner wrote:
>
> Hello,
>
> My interpretation of the use attribute is that it refers to the use of
> archetype from the clinical perspective, not from the legal one. I would
> not mix both things.
>
> Moreover, one of the new metadata requirements is to include the license
> of the archetype itself (not only the copyright). So probably this license
> and the third party licenses could be represented in the same place.
>
> David
>
>
>
>
> ___
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>
--
David Moner Cano
Grupo de Inform?tica Biom?dica - IBIME
Instituto ITACA
http://www.ibime.upv.es
http://www.linkedin.com/in/davidmoner
Universidad Polit?cnica de Valencia (UPV)
Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta
Valencia - 46022 (Espa?a)
-- next part ------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/01dbb438/attachment.html>
Archetypes - new meta-data elements for 3rd party copyrights?
The discussions on this wiki page http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Meta-data 2014-11-13 10:59 GMT+01:00 Ian McNicoll : > Hi Diego, > > I am not quite sure what you meant by that? > > Ian > > On 13 November 2014 09:56, Diego Bosc? wrote: >> If that's the case then we cannot assume any other attribute to be in >> the repository. >> >> 2014-11-13 10:52 GMT+01:00 Ian McNicoll : >>> Hi Diego, >>> >>> I did wonder about the idea of repository-level attribution but in >>> practice the archetypes will often be disconnected and shared in local >>> repositories etc, so I suspect we are stuck with attribution for each >>> archetype. >>> >>> I have looked at Thomas's proposal on the wiki and now think that is >>> probably the best answer. It keeps 'use' and 'references' for their >>> original intention and might make it easier to automate the import of >>> boilerplate term of use etc. e.g. The repository manager could check >>> for SNOMED CT and LOINC bindings on upload and offer to add the >>> requisite text. >>> >>> Ian >>> >>> >>> Dr Ian McNicoll >>> mobile +44 (0)775 209 7859 >>> office +44 (0)1536 414994 >>> skype: ianmcnicoll >>> email: ian at freshehr.com >>> twitter: @ianmcnicoll >>> >>> Director, freshEHR Clinical Informatics >>> Director, openEHR Foundation >>> Director, HANDIHealth CIC >>> Hon. Senior Research Associate, CHIME, UCL >>> >>> >>> On 13 November 2014 09:44, Diego Bosc? wrote: If the 3rd party attribution will be always the same, should not be stored in the repository or make that it is somewhat assumed for archetypes in a given domain instead of repeating it on each archetype? And as David says, a new metadata attribute was included to deal with this if still it is needed to be put (the barthel scale use case) 2014-11-13 10:36 GMT+01:00 Ian McNicoll >>> oceaninformatics.com>: > So we all would probably benefit from creating some copy and paste > examples for common 3rd party attribution that can be easily > incorporated into archetypes / resources. > > Ian > Dr Ian McNicoll > office +44 (0)1536 414 994 > fax +44 (0)1536 516317 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian.mcnicoll at oceaninformatics.com > > Clinical Modelling Consultant, Ocean Informatics, UK > Director openEHR Foundation www.openehr.org/knowledge > Honorary Senior Research Associate, CHIME, UCL > SCIMP Working Group, NHS Scotland > BCS Primary Health Care www.phcsg.org > > > On 13 November 2014 09:24, Grahame Grieve > wrote: >> you do not need to pay, but the licensing requirements are quite specific >> about what kind of attribution is required. >> >> Grahame >> >> >> On Thu, Nov 13, 2014 at 8:19 PM, Stefan Sauermann >> wrote: >>> >>> Hello! >>> We are using LOINC in Austria for coding lab results on a national >>> scale. >>> As far as I know nobody needs to pay anything to Regenstrief to do so. >>> >>> I am not aware of any "must mention Regenstrief" requirements, but I may >>> miss something. >>> Greetings from Vienna, >>> Stefan >>> >>> Stefan Sauermann >>> >>> Program Director >>> Biomedical Engineering Sciences (Master) >>> >>> University of Applied Sciences Technikum Wien >>> Hoechstaedtplatz 5, 1200 Vienna, Austria >>> P: +43 1 333 40 77 - 988 >>> M: +43 664 6192555 >>> E: stefan.sauermann at technikum-wien.at >>> >>> I: www.technikum-wien.at/mbe >>> I: www.technikum-wien.at/ibmt >>> I: www.healthy-interoperability.at >>> >>> Am 13.11.2014 10:07, schrieb Grahame Grieve: >>> >>> my advice from LOINC/regenstrief is that it does apply >>> >>> Grahame >>> >>> >>> On Thu, Nov 13, 2014 at 8:01 PM, Thomas Beale >>> wrote: Something that has become clear in CIMI, and will affect openEHR, 13606 and most likely any archetype developer is that acknowledgements of 3rd party copyrights and trademarks need to be made. The most obvious common one is likely to be for SNOMED CT codes in archetype bindings (Stan Huff at Intermountain is still working on whether such acknowledgements are needed for LOINC codes). However, it could be for anything, e.g. rights to use a scale like Barthel or Waterlow. At the moment there is no dedicated place in the model for this particular meta-data. It could just go in 'other_details' but I suspect that we need to be more precise than that. Consider for example, the openEHR Barthel scale archetype - it currently carries this text in the 'Use' section: Note: The Maryland State Medical Society holds the copyright for the Barthel Index. It may be used freely for no
Archetypes - new meta-data elements for 3rd party copyrights?
If that's the case then we cannot assume any other attribute to be in the repository. 2014-11-13 10:52 GMT+01:00 Ian McNicoll : > Hi Diego, > > I did wonder about the idea of repository-level attribution but in > practice the archetypes will often be disconnected and shared in local > repositories etc, so I suspect we are stuck with attribution for each > archetype. > > I have looked at Thomas's proposal on the wiki and now think that is > probably the best answer. It keeps 'use' and 'references' for their > original intention and might make it easier to automate the import of > boilerplate term of use etc. e.g. The repository manager could check > for SNOMED CT and LOINC bindings on upload and offer to add the > requisite text. > > Ian > > > Dr Ian McNicoll > mobile +44 (0)775 209 7859 > office +44 (0)1536 414994 > skype: ianmcnicoll > email: ian at freshehr.com > twitter: @ianmcnicoll > > Director, freshEHR Clinical Informatics > Director, openEHR Foundation > Director, HANDIHealth CIC > Hon. Senior Research Associate, CHIME, UCL > > > On 13 November 2014 09:44, Diego Bosc? wrote: >> If the 3rd party attribution will be always the same, should not be >> stored in the repository or make that it is somewhat assumed for >> archetypes in a given domain instead of repeating it on each >> archetype? >> And as David says, a new metadata attribute was included to deal with >> this if still it is needed to be put (the barthel scale use case) >> >> 2014-11-13 10:36 GMT+01:00 Ian McNicoll > oceaninformatics.com>: >>> So we all would probably benefit from creating some copy and paste >>> examples for common 3rd party attribution that can be easily >>> incorporated into archetypes / resources. >>> >>> Ian >>> Dr Ian McNicoll >>> office +44 (0)1536 414 994 >>> fax +44 (0)1536 516317 >>> mobile +44 (0)775 209 7859 >>> skype ianmcnicoll >>> ian.mcnicoll at oceaninformatics.com >>> >>> Clinical Modelling Consultant, Ocean Informatics, UK >>> Director openEHR Foundation www.openehr.org/knowledge >>> Honorary Senior Research Associate, CHIME, UCL >>> SCIMP Working Group, NHS Scotland >>> BCS Primary Health Care www.phcsg.org >>> >>> >>> On 13 November 2014 09:24, Grahame Grieve >>> wrote: you do not need to pay, but the licensing requirements are quite specific about what kind of attribution is required. Grahame On Thu, Nov 13, 2014 at 8:19 PM, Stefan Sauermann wrote: > > Hello! > We are using LOINC in Austria for coding lab results on a national scale. > As far as I know nobody needs to pay anything to Regenstrief to do so. > > I am not aware of any "must mention Regenstrief" requirements, but I may > miss something. > Greetings from Vienna, > Stefan > > Stefan Sauermann > > Program Director > Biomedical Engineering Sciences (Master) > > University of Applied Sciences Technikum Wien > Hoechstaedtplatz 5, 1200 Vienna, Austria > P: +43 1 333 40 77 - 988 > M: +43 664 6192555 > E: stefan.sauermann at technikum-wien.at > > I: www.technikum-wien.at/mbe > I: www.technikum-wien.at/ibmt > I: www.healthy-interoperability.at > > Am 13.11.2014 10:07, schrieb Grahame Grieve: > > my advice from LOINC/regenstrief is that it does apply > > Grahame > > > On Thu, Nov 13, 2014 at 8:01 PM, Thomas Beale > wrote: >> >> >> Something that has become clear in CIMI, and will affect openEHR, 13606 >> and most likely any archetype developer is that acknowledgements of 3rd >> party copyrights and trademarks need to be made. The most obvious common >> one >> is likely to be for SNOMED CT codes in archetype bindings (Stan Huff at >> Intermountain is still working on whether such acknowledgements are >> needed >> for LOINC codes). However, it could be for anything, e.g. rights to use a >> scale like Barthel or Waterlow. >> >> At the moment there is no dedicated place in the model for this >> particular meta-data. It could just go in 'other_details' but I suspect >> that >> we need to be more precise than that. Consider for example, the openEHR >> Barthel scale archetype - it currently carries this text in the 'Use' >> section: >> >> Note: >> The Maryland State Medical Society holds the copyright for the Barthel >> Index. It may be used freely for non-commercial purposes with the >> following >> citation: >> Mahoney FI, Barthel D. ?Functional evaluation: the Barthel Index.? >> Maryland State Med Journal 1965;14:56-61. Used with permission. >> >> Permission is required to modify the Barthel Index or to use it for >> commercial purposes. >> >> This seems less than optimal, and is certainly not going to be reliably >> tool-separable from the main 'Use' content, since the word 'Note:' and >> the >> placement of this text are purely local
Archetypes - new meta-data elements for 3rd party copyrights?
If the 3rd party attribution will be always the same, should not be stored in the repository or make that it is somewhat assumed for archetypes in a given domain instead of repeating it on each archetype? And as David says, a new metadata attribute was included to deal with this if still it is needed to be put (the barthel scale use case) 2014-11-13 10:36 GMT+01:00 Ian McNicoll : > So we all would probably benefit from creating some copy and paste > examples for common 3rd party attribution that can be easily > incorporated into archetypes / resources. > > Ian > Dr Ian McNicoll > office +44 (0)1536 414 994 > fax +44 (0)1536 516317 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian.mcnicoll at oceaninformatics.com > > Clinical Modelling Consultant, Ocean Informatics, UK > Director openEHR Foundation www.openehr.org/knowledge > Honorary Senior Research Associate, CHIME, UCL > SCIMP Working Group, NHS Scotland > BCS Primary Health Care www.phcsg.org > > > On 13 November 2014 09:24, Grahame Grieve > wrote: >> you do not need to pay, but the licensing requirements are quite specific >> about what kind of attribution is required. >> >> Grahame >> >> >> On Thu, Nov 13, 2014 at 8:19 PM, Stefan Sauermann >> wrote: >>> >>> Hello! >>> We are using LOINC in Austria for coding lab results on a national scale. >>> As far as I know nobody needs to pay anything to Regenstrief to do so. >>> >>> I am not aware of any "must mention Regenstrief" requirements, but I may >>> miss something. >>> Greetings from Vienna, >>> Stefan >>> >>> Stefan Sauermann >>> >>> Program Director >>> Biomedical Engineering Sciences (Master) >>> >>> University of Applied Sciences Technikum Wien >>> Hoechstaedtplatz 5, 1200 Vienna, Austria >>> P: +43 1 333 40 77 - 988 >>> M: +43 664 6192555 >>> E: stefan.sauermann at technikum-wien.at >>> >>> I: www.technikum-wien.at/mbe >>> I: www.technikum-wien.at/ibmt >>> I: www.healthy-interoperability.at >>> >>> Am 13.11.2014 10:07, schrieb Grahame Grieve: >>> >>> my advice from LOINC/regenstrief is that it does apply >>> >>> Grahame >>> >>> >>> On Thu, Nov 13, 2014 at 8:01 PM, Thomas Beale >>> wrote: Something that has become clear in CIMI, and will affect openEHR, 13606 and most likely any archetype developer is that acknowledgements of 3rd party copyrights and trademarks need to be made. The most obvious common one is likely to be for SNOMED CT codes in archetype bindings (Stan Huff at Intermountain is still working on whether such acknowledgements are needed for LOINC codes). However, it could be for anything, e.g. rights to use a scale like Barthel or Waterlow. At the moment there is no dedicated place in the model for this particular meta-data. It could just go in 'other_details' but I suspect that we need to be more precise than that. Consider for example, the openEHR Barthel scale archetype - it currently carries this text in the 'Use' section: Note: The Maryland State Medical Society holds the copyright for the Barthel Index. It may be used freely for non-commercial purposes with the following citation: Mahoney FI, Barthel D. ?Functional evaluation: the Barthel Index.? Maryland State Med Journal 1965;14:56-61. Used with permission. Permission is required to modify the Barthel Index or to use it for commercial purposes. This seems less than optimal, and is certainly not going to be reliably tool-separable from the main 'Use' content, since the word 'Note:' and the placement of this text are purely local choices. There is another issue here. The acknowledgement text actually included in the archetype needs to be minimal, and as far as legally possible not contain volatile elements that can change. Therefore, I think the general approach needs to be as is typically done with open source licences: not including the whole text, but including a reliable URL to the licence text either from the issuer (e.g. Creative Commons CC-BY page) or an agreement between the publisher and the licensor (e.g. between IHTSDO and CIMI for the use of SNOMED CT, and details of that use). I have updated the meta-data page on the wiki to indicate what I think is the requirement - see end of the main table. I am increasingly of the feeling that we need to act on this soon. - thomas ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >>> >>> >>> >>> >>> -- >>> - >>> http://www.healthintersections.com.au / grahame at >>> healthintersections.com.au >>> / +61 411 867 065 >>> >>> >>> ___ >>> openEHR-clinical mailing list >>> openEHR-clinical at lists.openehr.org
Archetypes - new meta-data elements for 3rd party copyrights?
On 13/11/2014 10:02, Heather Leslie wrote: > I've had discussions with IHTSDO about needing a formal statement about SCT > that should be placed in archetypes and this will be identical to that which > they are currently working on with CIMI. > > Regards > > Heather The main thing we need to do with this in my view is put most of such statements online in each user org (CIMI, Intermountain, openEHR etc) and make the text that is in the archetype itself as short as legally possible. Consider that putting the whole (identical) statement for each acknowledged type of IP in the current CIMI archetypes - 2200 of them - would a) dwarf the main content in most of those archetypes and b) create a source of unnecessary updates to archetypes. Consider a licence notice for SNOMED CT for example. If it mentions 'IHTSDO', it will most likely be out of date in a year's time if IHTSDO changes its name next year, as was talked about at the recent meeting in Amsterdam, and that's 2200 archetypes that have to be put through a revision and reissue process, unnecessarily. - thomas
Archetypes - new meta-data elements for 3rd party copyrights?
We also have the other_details references. If only a reference is required this could be the place for it, if a wordy attribution with constraints on how the archetype can be used is required, this could be in 'Use'. References could of course be made a dedicated field, rather than one that is used by convention in other_details. Sebastian On 13.11.2014 10:15, Ian McNicoll wrote: > I would agree with Heather. Put it in 'use'. > > My worry about having a dedicated attribute is that the requirements > may vary pretty widely from simple reference to wordy attribution (as > per the Barthel example). > > This also raises an issue about whether the Foundation should seek a > similar arrangement with IHTSDO re use of SNOMED CT terms. > > Ian > > > > > > On 13 November 2014 09:10, Heather Leslie > wrote: >> It is actually relevant to have this information in the ?Use? as it is a >> reasonable place to look to see constraints on use and how it should be >> implemented in systems. >> >> >> >> No reason why it can?t be in a dedicated/purpose-built place as well. >> >> >> >> Heather >> >> >> >> From: openEHR-technical [mailto:openehr-technical-bounces at >> lists.openehr.org] >> On Behalf Of Grahame Grieve >> Sent: Thursday, 13 November 2014 8:07 PM >> To: For openEHR clinical discussions >> Cc: Openehr-Technical >> Subject: Re: Archetypes - new meta-data elements for 3rd party copyrights? >> >> >> >> my advice from LOINC/regenstrief is that it does apply >> >> >> >> Grahame >> >> >> >> >> >> On Thu, Nov 13, 2014 at 8:01 PM, Thomas Beale >> wrote: >> >> >> Something that has become clear in CIMI, and will affect openEHR, 13606 and >> most likely any archetype developer is that acknowledgements of 3rd party >> copyrights and trademarks need to be made. The most obvious common one is >> likely to be for SNOMED CT codes in archetype bindings (Stan Huff at >> Intermountain is still working on whether such acknowledgements are needed >> for LOINC codes). However, it could be for anything, e.g. rights to use a >> scale like Barthel or Waterlow. >> >> At the moment there is no dedicated place in the model for this particular >> meta-data. It could just go in 'other_details' but I suspect that we need to >> be more precise than that. Consider for example, the openEHR Barthel scale >> archetype - it currently carries this text in the 'Use' section: >> >> Note: >> The Maryland State Medical Society holds the copyright for the Barthel >> Index. It may be used freely for non-commercial purposes with the following >> citation: >> Mahoney FI, Barthel D. ?Functional evaluation: the Barthel Index.? >> Maryland State Med Journal 1965;14:56-61. Used with permission. >> >> Permission is required to modify the Barthel Index or to use it for >> commercial purposes. >> >> This seems less than optimal, and is certainly not going to be reliably >> tool-separable from the main 'Use' content, since the word 'Note:' and the >> placement of this text are purely local choices. >> >> There is another issue here. The acknowledgement text actually included in >> the archetype needs to be minimal, and as far as legally possible not >> contain volatile elements that can change. Therefore, I think the general >> approach needs to be as is typically done with open source licences: not >> including the whole text, but including a reliable URL to the licence text >> either from the issuer (e.g. Creative Commons CC-BY page) or an agreement >> between the publisher and the licensor (e.g. between IHTSDO and CIMI for the >> use of SNOMED CT, and details of that use). >> >> I have updated the meta-data page on the wiki to indicate what I think is >> the requirement - see end of the main table. >> >> I am increasingly of the feeling that we need to act on this soon. >> >> - thomas >> >> >> ___ >> openEHR-clinical mailing list >> openEHR-clinical at lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-clinical_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 > > -- *Dr. Sebastian Garde* /Dr. sc. hum., Dipl.-Inform. Med, FACHI/ Ocean Informatics Skype: gardeseb -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/708df5fe/attachment.html>
Archetypes - new meta-data elements for 3rd party copyrights?
Hello, My interpretation of the use attribute is that it refers to the use of archetype from the clinical perspective, not from the legal one. I would not mix both things. Moreover, one of the new metadata requirements is to include the license of the archetype itself (not only the copyright). So probably this license and the third party licenses could be represented in the same place. David 2014-11-13 10:10 GMT+01:00 Heather Leslie < heather.leslie at oceaninformatics.com>: > It is actually relevant to have this information in the 'Use' as it is a > reasonable place to look to see constraints on use and how it should be > implemented in systems. > > > > No reason why it can't be in a dedicated/purpose-built place as well. > > > > Heather > > > > *From:* openEHR-technical [mailto: > openehr-technical-bounces at lists.openehr.org] *On Behalf Of *Grahame Grieve > *Sent:* Thursday, 13 November 2014 8:07 PM > *To:* For openEHR clinical discussions > *Cc:* Openehr-Technical > *Subject:* Re: Archetypes - new meta-data elements for 3rd party > copyrights? > > > > my advice from LOINC/regenstrief is that it does apply > > > > Grahame > > > > > > On Thu, Nov 13, 2014 at 8:01 PM, Thomas Beale < > thomas.beale at oceaninformatics.com> wrote: > > > Something that has become clear in CIMI, and will affect openEHR, 13606 > and most likely any archetype developer is that acknowledgements of 3rd > party copyrights and trademarks need to be made. The most obvious common > one is likely to be for SNOMED CT codes in archetype bindings (Stan Huff at > Intermountain is still working on whether such acknowledgements are needed > for LOINC codes). However, it could be for anything, e.g. rights to use a > scale like Barthel or Waterlow. > > At the moment there is no dedicated place in the model for this particular > meta-data. It could just go in 'other_details' but I suspect that we need > to be more precise than that. Consider for example, the openEHR Barthel > scale archetype - it currently carries this text in the 'Use' section: > > Note: > The Maryland State Medical Society holds the copyright for the Barthel > Index. It may be used freely for non-commercial purposes with the > following citation: > Mahoney FI, Barthel D. "Functional evaluation: the Barthel Index." > Maryland State Med Journal 1965;14:56-61. Used with permission. > > Permission is required to modify the Barthel Index or to use it for > commercial purposes. > > This seems less than optimal, and is certainly not going to be reliably > tool-separable from the main 'Use' content, since the word 'Note:' and the > placement of this text are purely local choices. > > There is another issue here. The acknowledgement text actually included in > the archetype needs to be minimal, and as far as legally possible not > contain volatile elements that can change. Therefore, I think the general > approach needs to be as is typically done with open source licences: not > including the whole text, but including a reliable URL to the licence text > either from the issuer (e.g. Creative Commons CC-BY page) or an agreement > between the publisher and the licensor (e.g. between IHTSDO and CIMI for > the use of SNOMED CT, and details of that use). > > I have updated the meta-data page on the wiki > <http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Meta-data>to > indicate what I think is the requirement - see end of the main table. > > I am increasingly of the feeling that we need to act on this soon. > > - thomas > > > ___ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_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 > -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es http://www.linkedin.com/in/davidmoner Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia - 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/e9077399/attachment-0001.html>
Archetypes - new meta-data elements for 3rd party copyrights?
I've had discussions with IHTSDO about needing a formal statement about SCT that should be placed in archetypes and this will be identical to that which they are currently working on with CIMI. Regards Heather > -Original Message- > From: openEHR-technical [mailto:openehr-technical- > bounces at lists.openehr.org] On Behalf Of Ian McNicoll > Sent: Thursday, 13 November 2014 8:15 PM > To: For openEHR technical discussions > Cc: For openEHR clinical discussions > Subject: Re: Archetypes - new meta-data elements for 3rd party copyrights? > > I would agree with Heather. Put it in 'use'. > > My worry about having a dedicated attribute is that the requirements may vary > pretty widely from simple reference to wordy attribution (as per the Barthel > example). > > This also raises an issue about whether the Foundation should seek a similar > arrangement with IHTSDO re use of SNOMED CT terms. > > Ian > > > > > > On 13 November 2014 09:10, Heather Leslie > wrote: > > It is actually relevant to have this information in the ?Use? as it is > > a reasonable place to look to see constraints on use and how it should > > be implemented in systems. > > > > > > > > No reason why it can?t be in a dedicated/purpose-built place as well. > > > > > > > > Heather > > > > > > > > From: openEHR-technical > > [mailto:openehr-technical-bounces at lists.openehr.org] > > On Behalf Of Grahame Grieve > > Sent: Thursday, 13 November 2014 8:07 PM > > To: For openEHR clinical discussions > > Cc: Openehr-Technical > > Subject: Re: Archetypes - new meta-data elements for 3rd party copyrights? > > > > > > > > my advice from LOINC/regenstrief is that it does apply > > > > > > > > Grahame > > > > > > > > > > > > On Thu, Nov 13, 2014 at 8:01 PM, Thomas Beale > > wrote: > > > > > > Something that has become clear in CIMI, and will affect openEHR, > > 13606 and most likely any archetype developer is that acknowledgements > > of 3rd party copyrights and trademarks need to be made. The most > > obvious common one is likely to be for SNOMED CT codes in archetype > > bindings (Stan Huff at Intermountain is still working on whether such > > acknowledgements are needed for LOINC codes). However, it could be for > > anything, e.g. rights to use a scale like Barthel or Waterlow. > > > > At the moment there is no dedicated place in the model for this > > particular meta-data. It could just go in 'other_details' but I > > suspect that we need to be more precise than that. Consider for > > example, the openEHR Barthel scale archetype - it currently carries this > > text > in the 'Use' section: > > > > Note: > > The Maryland State Medical Society holds the copyright for the Barthel > > Index. It may be used freely for non-commercial purposes with the > > following > > citation: > > Mahoney FI, Barthel D. ?Functional evaluation: the Barthel Index.? > > Maryland State Med Journal 1965;14:56-61. Used with permission. > > > > Permission is required to modify the Barthel Index or to use it for > > commercial purposes. > > > > This seems less than optimal, and is certainly not going to be > > reliably tool-separable from the main 'Use' content, since the word > > 'Note:' and the placement of this text are purely local choices. > > > > There is another issue here. The acknowledgement text actually > > included in the archetype needs to be minimal, and as far as legally > > possible not contain volatile elements that can change. Therefore, I > > think the general approach needs to be as is typically done with open > > source licences: not including the whole text, but including a > > reliable URL to the licence text either from the issuer (e.g. Creative > > Commons CC-BY page) or an agreement between the publisher and the > > licensor (e.g. between IHTSDO and CIMI for the use of SNOMED CT, and > details of that use). > > > > I have updated the meta-data page on the wiki to indicate what I think > > is the requirement - see end of the main table. > > > > I am increasingly of the feeling that we need to act on this soon. > > > > - thomas > > > > > > ___ > > openEHR-clinical mailing list > > openEHR-clinical at lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.opene > > hr.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.open > > ehr.org > > > > -- > Dr Ian McNicoll > office +44 (0)1536 414 994 > fax +44 (0)1536 516317 > mobile +44 (0)775 209 7859 > skype ianmcnicoll > ian.mcnicoll at oceaninformatics.com > > Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR > Foundation www.openehr.org/knowledge Honorary Senior Research > Associate,
Archetypes - new meta-data elements for 3rd party copyrights?
Hi Diego, I am not quite sure what you meant by that? Ian On 13 November 2014 09:56, Diego Bosc? wrote: > If that's the case then we cannot assume any other attribute to be in > the repository. > > 2014-11-13 10:52 GMT+01:00 Ian McNicoll : >> Hi Diego, >> >> I did wonder about the idea of repository-level attribution but in >> practice the archetypes will often be disconnected and shared in local >> repositories etc, so I suspect we are stuck with attribution for each >> archetype. >> >> I have looked at Thomas's proposal on the wiki and now think that is >> probably the best answer. It keeps 'use' and 'references' for their >> original intention and might make it easier to automate the import of >> boilerplate term of use etc. e.g. The repository manager could check >> for SNOMED CT and LOINC bindings on upload and offer to add the >> requisite text. >> >> Ian >> >> >> Dr Ian McNicoll >> mobile +44 (0)775 209 7859 >> office +44 (0)1536 414994 >> skype: ianmcnicoll >> email: ian at freshehr.com >> twitter: @ianmcnicoll >> >> Director, freshEHR Clinical Informatics >> Director, openEHR Foundation >> Director, HANDIHealth CIC >> Hon. Senior Research Associate, CHIME, UCL >> >> >> On 13 November 2014 09:44, Diego Bosc? wrote: >>> If the 3rd party attribution will be always the same, should not be >>> stored in the repository or make that it is somewhat assumed for >>> archetypes in a given domain instead of repeating it on each >>> archetype? >>> And as David says, a new metadata attribute was included to deal with >>> this if still it is needed to be put (the barthel scale use case) >>> >>> 2014-11-13 10:36 GMT+01:00 Ian McNicoll >> oceaninformatics.com>: So we all would probably benefit from creating some copy and paste examples for common 3rd party attribution that can be easily incorporated into archetypes / resources. Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org On 13 November 2014 09:24, Grahame Grieve wrote: > you do not need to pay, but the licensing requirements are quite specific > about what kind of attribution is required. > > Grahame > > > On Thu, Nov 13, 2014 at 8:19 PM, Stefan Sauermann > wrote: >> >> Hello! >> We are using LOINC in Austria for coding lab results on a national scale. >> As far as I know nobody needs to pay anything to Regenstrief to do so. >> >> I am not aware of any "must mention Regenstrief" requirements, but I may >> miss something. >> Greetings from Vienna, >> Stefan >> >> Stefan Sauermann >> >> Program Director >> Biomedical Engineering Sciences (Master) >> >> University of Applied Sciences Technikum Wien >> Hoechstaedtplatz 5, 1200 Vienna, Austria >> P: +43 1 333 40 77 - 988 >> M: +43 664 6192555 >> E: stefan.sauermann at technikum-wien.at >> >> I: www.technikum-wien.at/mbe >> I: www.technikum-wien.at/ibmt >> I: www.healthy-interoperability.at >> >> Am 13.11.2014 10:07, schrieb Grahame Grieve: >> >> my advice from LOINC/regenstrief is that it does apply >> >> Grahame >> >> >> On Thu, Nov 13, 2014 at 8:01 PM, Thomas Beale >> wrote: >>> >>> >>> Something that has become clear in CIMI, and will affect openEHR, 13606 >>> and most likely any archetype developer is that acknowledgements of 3rd >>> party copyrights and trademarks need to be made. The most obvious >>> common one >>> is likely to be for SNOMED CT codes in archetype bindings (Stan Huff at >>> Intermountain is still working on whether such acknowledgements are >>> needed >>> for LOINC codes). However, it could be for anything, e.g. rights to use >>> a >>> scale like Barthel or Waterlow. >>> >>> At the moment there is no dedicated place in the model for this >>> particular meta-data. It could just go in 'other_details' but I suspect >>> that >>> we need to be more precise than that. Consider for example, the openEHR >>> Barthel scale archetype - it currently carries this text in the 'Use' >>> section: >>> >>> Note: >>> The Maryland State Medical Society holds the copyright for the Barthel >>> Index. It may be used freely for non-commercial purposes with the >>> following >>> citation: >>> Mahoney FI, Barthel D. ?Functional evaluation: the Barthel Index.? >>> Maryland State Med Journal 1965;14:56-61. Used with permission. >>> >>> Permission is required to modify the Barthel Index or to use it
Archetypes - new meta-data elements for 3rd party copyrights?
Hi David,
licence is taken care of in the model as it is today
<http://www.openehr.org/wiki/download/attachments/45645905/AOM_archetype_package.png?version=2&modificationDate=1412032298000&api=v2>.
Note that it is currently spelt in international English, not US English
('license', which is only a verb in International English).
- thomas
On 13/11/2014 09:30, David Moner wrote:
> Hello,
>
> My interpretation of the use attribute is that it refers to the use of
> archetype from the clinical perspective, not from the legal one. I
> would not mix both things.
>
> Moreover, one of the new metadata requirements is to include the
> license of the archetype itself (not only the copyright). So probably
> this license and the third party licenses could be represented in the
> same place.
>
> David
>
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/7da6e608/attachment.html>
Archetypes - new meta-data elements for 3rd party copyrights?
Well, my point here isn't to discuss whether LOINC needs to be mentioned, it's to determine the way for general recognition of 3rd party IP used in the artefact. - thomas On 13/11/2014 09:27, Jussara Rotzsch wrote: > https://loinc.org/terms-of-use > > Enviado do meu iPad -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/6e0eb449/attachment.html>
Archetypes - new meta-data elements for 3rd party copyrights?
On 13/11/2014 09:10, Heather Leslie wrote: > > It is actually relevant to have this information in the ?Use? as it is > a reasonable place to look to see constraints on use and how it should > be implemented in systems. > > No reason why it can?t be in a dedicated/purpose-built place as well. > right - that's a good point because there may be some clinically relevant statement to make, especially like in the Barthel case. But I believe there needs to be an easily findable legal form of statement that recognises each 3rd party IP implicated in the archetype - and I think that the latter statements are more likely to be legal-ish words + URLs. - thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/2c41ae3f/attachment.html>
Archetypes - new meta-data elements for 3rd party copyrights?
Hi Diego, I did wonder about the idea of repository-level attribution but in practice the archetypes will often be disconnected and shared in local repositories etc, so I suspect we are stuck with attribution for each archetype. I have looked at Thomas's proposal on the wiki and now think that is probably the best answer. It keeps 'use' and 'references' for their original intention and might make it easier to automate the import of boilerplate term of use etc. e.g. The repository manager could check for SNOMED CT and LOINC bindings on upload and offer to add the requisite text. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: ian at freshehr.com twitter: @ianmcnicoll Director, freshEHR Clinical Informatics Director, openEHR Foundation Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 13 November 2014 09:44, Diego Bosc? wrote: > If the 3rd party attribution will be always the same, should not be > stored in the repository or make that it is somewhat assumed for > archetypes in a given domain instead of repeating it on each > archetype? > And as David says, a new metadata attribute was included to deal with > this if still it is needed to be put (the barthel scale use case) > > 2014-11-13 10:36 GMT+01:00 Ian McNicoll oceaninformatics.com>: >> So we all would probably benefit from creating some copy and paste >> examples for common 3rd party attribution that can be easily >> incorporated into archetypes / resources. >> >> Ian >> Dr Ian McNicoll >> office +44 (0)1536 414 994 >> fax +44 (0)1536 516317 >> mobile +44 (0)775 209 7859 >> skype ianmcnicoll >> ian.mcnicoll at oceaninformatics.com >> >> Clinical Modelling Consultant, Ocean Informatics, UK >> Director openEHR Foundation www.openehr.org/knowledge >> Honorary Senior Research Associate, CHIME, UCL >> SCIMP Working Group, NHS Scotland >> BCS Primary Health Care www.phcsg.org >> >> >> On 13 November 2014 09:24, Grahame Grieve >> wrote: >>> you do not need to pay, but the licensing requirements are quite specific >>> about what kind of attribution is required. >>> >>> Grahame >>> >>> >>> On Thu, Nov 13, 2014 at 8:19 PM, Stefan Sauermann >>> wrote: Hello! We are using LOINC in Austria for coding lab results on a national scale. As far as I know nobody needs to pay anything to Regenstrief to do so. I am not aware of any "must mention Regenstrief" requirements, but I may miss something. Greetings from Vienna, Stefan Stefan Sauermann Program Director Biomedical Engineering Sciences (Master) University of Applied Sciences Technikum Wien Hoechstaedtplatz 5, 1200 Vienna, Austria P: +43 1 333 40 77 - 988 M: +43 664 6192555 E: stefan.sauermann at technikum-wien.at I: www.technikum-wien.at/mbe I: www.technikum-wien.at/ibmt I: www.healthy-interoperability.at Am 13.11.2014 10:07, schrieb Grahame Grieve: my advice from LOINC/regenstrief is that it does apply Grahame On Thu, Nov 13, 2014 at 8:01 PM, Thomas Beale wrote: > > > Something that has become clear in CIMI, and will affect openEHR, 13606 > and most likely any archetype developer is that acknowledgements of 3rd > party copyrights and trademarks need to be made. The most obvious common > one > is likely to be for SNOMED CT codes in archetype bindings (Stan Huff at > Intermountain is still working on whether such acknowledgements are needed > for LOINC codes). However, it could be for anything, e.g. rights to use a > scale like Barthel or Waterlow. > > At the moment there is no dedicated place in the model for this > particular meta-data. It could just go in 'other_details' but I suspect > that > we need to be more precise than that. Consider for example, the openEHR > Barthel scale archetype - it currently carries this text in the 'Use' > section: > > Note: > The Maryland State Medical Society holds the copyright for the Barthel > Index. It may be used freely for non-commercial purposes with the > following > citation: > Mahoney FI, Barthel D. ?Functional evaluation: the Barthel Index.? > Maryland State Med Journal 1965;14:56-61. Used with permission. > > Permission is required to modify the Barthel Index or to use it for > commercial purposes. > > This seems less than optimal, and is certainly not going to be reliably > tool-separable from the main 'Use' content, since the word 'Note:' and the > placement of this text are purely local choices. > > There is another issue here. The acknowledgement text actually included > in the archetype needs to be minimal, and as far as legally possible not > contain volatile elements that can change. Therefore, I think the general > approach needs to be as is typically done wi
Archetypes - new meta-data elements for 3rd party copyrights?
So we all would probably benefit from creating some copy and paste examples for common 3rd party attribution that can be easily incorporated into archetypes / resources. Ian Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org On 13 November 2014 09:24, Grahame Grieve wrote: > you do not need to pay, but the licensing requirements are quite specific > about what kind of attribution is required. > > Grahame > > > On Thu, Nov 13, 2014 at 8:19 PM, Stefan Sauermann > wrote: >> >> Hello! >> We are using LOINC in Austria for coding lab results on a national scale. >> As far as I know nobody needs to pay anything to Regenstrief to do so. >> >> I am not aware of any "must mention Regenstrief" requirements, but I may >> miss something. >> Greetings from Vienna, >> Stefan >> >> Stefan Sauermann >> >> Program Director >> Biomedical Engineering Sciences (Master) >> >> University of Applied Sciences Technikum Wien >> Hoechstaedtplatz 5, 1200 Vienna, Austria >> P: +43 1 333 40 77 - 988 >> M: +43 664 6192555 >> E: stefan.sauermann at technikum-wien.at >> >> I: www.technikum-wien.at/mbe >> I: www.technikum-wien.at/ibmt >> I: www.healthy-interoperability.at >> >> Am 13.11.2014 10:07, schrieb Grahame Grieve: >> >> my advice from LOINC/regenstrief is that it does apply >> >> Grahame >> >> >> On Thu, Nov 13, 2014 at 8:01 PM, Thomas Beale >> wrote: >>> >>> >>> Something that has become clear in CIMI, and will affect openEHR, 13606 >>> and most likely any archetype developer is that acknowledgements of 3rd >>> party copyrights and trademarks need to be made. The most obvious common one >>> is likely to be for SNOMED CT codes in archetype bindings (Stan Huff at >>> Intermountain is still working on whether such acknowledgements are needed >>> for LOINC codes). However, it could be for anything, e.g. rights to use a >>> scale like Barthel or Waterlow. >>> >>> At the moment there is no dedicated place in the model for this >>> particular meta-data. It could just go in 'other_details' but I suspect that >>> we need to be more precise than that. Consider for example, the openEHR >>> Barthel scale archetype - it currently carries this text in the 'Use' >>> section: >>> >>> Note: >>> The Maryland State Medical Society holds the copyright for the Barthel >>> Index. It may be used freely for non-commercial purposes with the following >>> citation: >>> Mahoney FI, Barthel D. ?Functional evaluation: the Barthel Index.? >>> Maryland State Med Journal 1965;14:56-61. Used with permission. >>> >>> Permission is required to modify the Barthel Index or to use it for >>> commercial purposes. >>> >>> This seems less than optimal, and is certainly not going to be reliably >>> tool-separable from the main 'Use' content, since the word 'Note:' and the >>> placement of this text are purely local choices. >>> >>> There is another issue here. The acknowledgement text actually included >>> in the archetype needs to be minimal, and as far as legally possible not >>> contain volatile elements that can change. Therefore, I think the general >>> approach needs to be as is typically done with open source licences: not >>> including the whole text, but including a reliable URL to the licence text >>> either from the issuer (e.g. Creative Commons CC-BY page) or an agreement >>> between the publisher and the licensor (e.g. between IHTSDO and CIMI for the >>> use of SNOMED CT, and details of that use). >>> >>> I have updated the meta-data page on the wiki to indicate what I think is >>> the requirement - see end of the main table. >>> >>> I am increasingly of the feeling that we need to act on this soon. >>> >>> - thomas >>> >>> ___ >>> openEHR-clinical mailing list >>> openEHR-clinical at lists.openehr.org >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org >> >> >> >> >> -- >> - >> http://www.healthintersections.com.au / grahame at healthintersections.com.au >> / +61 411 867 065 >> >> >> ___ >> openEHR-clinical mailing list >> openEHR-clinical at lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-clinical_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
Archetypes - new meta-data elements for 3rd party copyrights?
I would agree with Heather. Put it in 'use'. My worry about having a dedicated attribute is that the requirements may vary pretty widely from simple reference to wordy attribution (as per the Barthel example). This also raises an issue about whether the Foundation should seek a similar arrangement with IHTSDO re use of SNOMED CT terms. Ian On 13 November 2014 09:10, Heather Leslie wrote: > It is actually relevant to have this information in the ?Use? as it is a > reasonable place to look to see constraints on use and how it should be > implemented in systems. > > > > No reason why it can?t be in a dedicated/purpose-built place as well. > > > > Heather > > > > From: openEHR-technical [mailto:openehr-technical-bounces at > lists.openehr.org] > On Behalf Of Grahame Grieve > Sent: Thursday, 13 November 2014 8:07 PM > To: For openEHR clinical discussions > Cc: Openehr-Technical > Subject: Re: Archetypes - new meta-data elements for 3rd party copyrights? > > > > my advice from LOINC/regenstrief is that it does apply > > > > Grahame > > > > > > On Thu, Nov 13, 2014 at 8:01 PM, Thomas Beale > wrote: > > > Something that has become clear in CIMI, and will affect openEHR, 13606 and > most likely any archetype developer is that acknowledgements of 3rd party > copyrights and trademarks need to be made. The most obvious common one is > likely to be for SNOMED CT codes in archetype bindings (Stan Huff at > Intermountain is still working on whether such acknowledgements are needed > for LOINC codes). However, it could be for anything, e.g. rights to use a > scale like Barthel or Waterlow. > > At the moment there is no dedicated place in the model for this particular > meta-data. It could just go in 'other_details' but I suspect that we need to > be more precise than that. Consider for example, the openEHR Barthel scale > archetype - it currently carries this text in the 'Use' section: > > Note: > The Maryland State Medical Society holds the copyright for the Barthel > Index. It may be used freely for non-commercial purposes with the following > citation: > Mahoney FI, Barthel D. ?Functional evaluation: the Barthel Index.? > Maryland State Med Journal 1965;14:56-61. Used with permission. > > Permission is required to modify the Barthel Index or to use it for > commercial purposes. > > This seems less than optimal, and is certainly not going to be reliably > tool-separable from the main 'Use' content, since the word 'Note:' and the > placement of this text are purely local choices. > > There is another issue here. The acknowledgement text actually included in > the archetype needs to be minimal, and as far as legally possible not > contain volatile elements that can change. Therefore, I think the general > approach needs to be as is typically done with open source licences: not > including the whole text, but including a reliable URL to the licence text > either from the issuer (e.g. Creative Commons CC-BY page) or an agreement > between the publisher and the licensor (e.g. between IHTSDO and CIMI for the > use of SNOMED CT, and details of that use). > > I have updated the meta-data page on the wiki to indicate what I think is > the requirement - see end of the main table. > > I am increasingly of the feeling that we need to act on this soon. > > - thomas > > > ___ > openEHR-clinical mailing list > openEHR-clinical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-clinical_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 -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org
Archetypes - new meta-data elements for 3rd party copyrights?
It is actually relevant to have this information in the ?Use? as it is a reasonable place to look to see constraints on use and how it should be implemented in systems. No reason why it can?t be in a dedicated/purpose-built place as well. Heather From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Grahame Grieve Sent: Thursday, 13 November 2014 8:07 PM To: For openEHR clinical discussions Cc: Openehr-Technical Subject: Re: Archetypes - new meta-data elements for 3rd party copyrights? my advice from LOINC/regenstrief is that it does apply Grahame On Thu, Nov 13, 2014 at 8:01 PM, Thomas Beale mailto:thomas.beale at oceaninformatics.com>> wrote: Something that has become clear in CIMI, and will affect openEHR, 13606 and most likely any archetype developer is that acknowledgements of 3rd party copyrights and trademarks need to be made. The most obvious common one is likely to be for SNOMED CT codes in archetype bindings (Stan Huff at Intermountain is still working on whether such acknowledgements are needed for LOINC codes). However, it could be for anything, e.g. rights to use a scale like Barthel or Waterlow. At the moment there is no dedicated place in the model for this particular meta-data. It could just go in 'other_details' but I suspect that we need to be more precise than that. Consider for example, the openEHR Barthel scale archetype - it currently carries this text in the 'Use' section: Note: The Maryland State Medical Society holds the copyright for the Barthel Index. It may be used freely for non-commercial purposes with the following citation: Mahoney FI, Barthel D. ?Functional evaluation: the Barthel Index.? Maryland State Med Journal 1965;14:56-61. Used with permission. Permission is required to modify the Barthel Index or to use it for commercial purposes. This seems less than optimal, and is certainly not going to be reliably tool-separable from the main 'Use' content, since the word 'Note:' and the placement of this text are purely local choices. There is another issue here. The acknowledgement text actually included in the archetype needs to be minimal, and as far as legally possible not contain volatile elements that can change. Therefore, I think the general approach needs to be as is typically done with open source licences: not including the whole text, but including a reliable URL to the licence text either from the issuer (e.g. Creative Commons CC-BY page) or an agreement between the publisher and the licensor (e.g. between IHTSDO and CIMI for the use of SNOMED CT, and details of that use). I have updated the meta-data page on the wiki <http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Meta-data> to indicate what I think is the requirement - see end of the main table. I am increasingly of the feeling that we need to act on this soon. - thomas ___ openEHR-clinical mailing list openEHR-clinical at lists.openehr.org<mailto:openEHR-clinical at lists.openehr.org> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org -- - http://www.healthintersections.com.au / grahame at healthintersections.com.au<mailto:grahame at healthintersections.com.au> / +61 411 867 065 -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/13720d3f/attachment-0001.html>
Archetypes - new meta-data elements for 3rd party copyrights?
Something that has become clear in CIMI, and will affect openEHR, 13606 and most likely any archetype developer is that acknowledgements of 3rd party copyrights and trademarks need to be made. The most obvious common one is likely to be for SNOMED CT codes in archetype bindings (Stan Huff at Intermountain is still working on whether such acknowledgements are needed for LOINC codes). However, it could be for anything, e.g. rights to use a scale like Barthel or Waterlow. At the moment there is no dedicated place in the model for this particular meta-data. It could just go in 'other_details' but I suspect that we need to be more precise than that. Consider for example, the openEHR Barthel scale archetype - it currently carries this text in the 'Use' section: Note: The Maryland State Medical Society holds the copyright for the Barthel Index. It may be used freely for non-commercial purposes with the following citation: Mahoney FI, Barthel D. ?Functional evaluation: the Barthel Index.? Maryland State Med Journal 1965;14:56-61. Used with permission. Permission is required to modify the Barthel Index or to use it for commercial purposes. This seems less than optimal, and is certainly not going to be reliably tool-separable from the main 'Use' content, since the word 'Note:' and the placement of this text are purely local choices. There is another issue here. The acknowledgement text actually included in the archetype needs to be minimal, and as far as legally possible not contain volatile elements that can change. Therefore, I think the general approach needs to be as is typically done with open source licences: not including the whole text, but including a reliable URL to the licence text either from the issuer (e.g. Creative Commons CC-BY page) or an agreement between the publisher and the licensor (e.g. between IHTSDO and CIMI for the use of SNOMED CT, and details of that use). I have updated the meta-data page on the wiki <http://www.openehr.org/wiki/display/ADL/Knowledge+Artefact+Meta-data>to indicate what I think is the requirement - see end of the main table. I am increasingly of the feeling that we need to act on this soon. - thomas -- next part -- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141113/dac592df/attachment.html>
