FHIR Chat · Term of use for core CS with ISO 21089 Lifecycle Event codes · terminology

Stream: terminology

Topic: Term of use for core CS with ISO 21089 Lifecycle Event codes


view this post on Zulip Morten Ernebjerg (Aug 05 2021 at 12:28):

On terminology.hl7.org, I came across a code system that contains lifecycle event codes from the ISO 21089 standard (http://terminology.hl7.org/CodeSystem/iso-21089-lifecycle). The copyright clause on the associated page states that the copyright belongs to ISO and points to their web site. Now I am unsure what that actually means in terms of how this code system can be used. I.e. can I freely use all codes from this CS in an IG, can I store the CS on my system, can I use it in resources I create etc.?

I actually found myself asking similar questions before. So I'm also wondering if there are guidelines somewhere of how to ascertain the term of use for code systems or value sets the that are published as part of the core spec. I imagine many people might simply assume they are always free to use given that the whole FHIR spec is free, but clearly it is not that simple e.g. for sets composed of SNOMED CT codes.

view this post on Zulip Lloyd McKenzie (Aug 05 2021 at 15:04):

@Carol Macumber Agree that it could be helpful if the license text made clear what use is permitted - is this something that HTA can consider when defining/negotiating what the copyright text should say?

view this post on Zulip John Moehrke (Aug 05 2021 at 16:17):

there is a skills gap between the person charged with authoring the CodeSystem or ValueSet; with the reader that is expecting a legal opinion. I think all we can indicate is the copywrite holder. We should not expect the text to have the legal meaning or opinion. That should be left up to lawyers.

view this post on Zulip Lloyd McKenzie (Aug 05 2021 at 16:23):

I'm not expecting a legal opinion, but an indication of whether the code system has an open license or whether you need license permission or whether "it's complicated, talk to your lawyers" would be helpful.

view this post on Zulip John Moehrke (Aug 05 2021 at 16:24):

that is an opinion.. and one that changes possibly after the author is done publishing the codeSystem into THO

view this post on Zulip Lloyd McKenzie (Aug 05 2021 at 16:42):

If content is released under an open license, what's released is open, regardless of what the author does with subsequent versions. As well, FHIR has a policy that 'international' specs aren't allowed to have required or extensible bindings to terminologies without open licenses, so differentiating is actually important not only for implementers but also for HL7 authors.

view this post on Zulip John Moehrke (Aug 05 2021 at 17:16):

again, you are making a legal opinion. this is not a fundamental legal truth, and indeed HL7 itself has changed licensing over time.

view this post on Zulip Lloyd McKenzie (Aug 05 2021 at 17:37):

Sure, but the publications issued under the old license are available under the old license. License changes can't be retroactive. If LOINC chooses to impose a payment requirement to use their codes, they could (maybe - there's contributor considerations there too). But if we're bringing across content into our publication mechanism, we can reflect the status of the license at the time we grabbed the content - which is all that matters for those who use the content we've hosted. And for code systems where we don't bring in the content, we can at least reflect what the license was as of a particular date.

view this post on Zulip Morten Ernebjerg (Aug 06 2021 at 07:47):

I absolutely appreciate that this is a very difficult area. I know all too well well from personal experience how complicated and time-consuming terms-of-use checks can be. But exactly for that reason. I think a significant factor for implementability is (1) minimizing the no. of places in the core spec when implementers are forced to do such checks, and (2) clearly flagging those places. From e.g. @Lloyd McKenzie 's comment about the rule against tightly binding codes with licenses, it is clear that it's a known concern. So I suppose my comment is more about making the categories visible, e.g. by very clearly flagging all codes that are definitely free to use (just the binary "OK vs. complicated" distinction @Lloyd McKenzie is talking about). This also holds where binding are merely preferred or exemplary, as many implementors are probably likely to grab those. How many CSs/VSs could actually get such a "seal of free use" would then depend on the legal conditions and effort involved - but the more the better for implementers :smile:.

BTW, all codes from the ISO CS I mentioned are part of a VS that is extensibly bound to Provenance.activity in the latest build, so by the spec binding rules that should mean that they must either be under an open license or must be removed from the VS. But @John Moehrke, if I understood you right, there might end up only being only an example binding on activity in R5?

view this post on Zulip John Moehrke (Aug 06 2021 at 13:51):

lucky for me, I am removing them from the valuesets and changing to example binding.

view this post on Zulip Michael Lawley (Aug 09 2021 at 21:50):

I think you need to clarify what an "open licence" is. LOINC imposes some very strict limitations on how codes can be used, and ICD is also not unencumbered.

view this post on Zulip Lloyd McKenzie (Aug 09 2021 at 22:22):

My definition is that, regardless of country, no payment is required to capture, exchange or display them or their designations or to have or use the information within the code system necessary to expand a value set or for an analyst to map to or from the codes.

view this post on Zulip Carol Macumber (Aug 16 2021 at 17:34):

@Lloyd McKenzie Yes, part of HTA's process (to-date, for the external code systems either heavily used or brought to it's attention) is to provide information on both Copyright and IP. Further, if there is an agreement in place with HL7, or one in progress, that is also noted. There are many external code systems that were migrated over to THO that have not been brought to HTA for further analysis or specification. Sounds like this one would benefit from some additional detail and an HTA external code system confluence page (which will eventually be migrated to TO). @Reuben Daniels FYI, I've added this one to the agenda of our next call for assignment to an HTA member.


Last updated: Apr 12 2022 at 19:14 UTC