FHIR Chat · epSOS/ehDSI MVC Translations · europe

Stream: europe

Topic: epSOS/ehDSI MVC Translations


view this post on Zulip Alexander Henket (Jun 11 2020 at 10:05):

The Netherlands is one of multiple countries tasked with translating terms in the ehDSI MVC, master value sets catalog. A lot of the terms in there originate in HL7 CodeSystems. ehDSI is one the many use cases for translations of these terms and it would be a crying shame not to bring those to HL7 for 'the world to enjoy'.

To that end I've reached out to HTA and Vocabulary to see if we could think of a process to do so. Technically speaking it could entail something like "deliver CodeSystem supplements to UTG and publish them in UTG for view and download".

What I don't know in all this is how other countries in Europe think about this. It seems so far that no other country thought of bringing results back to HL7.

Can we somehow join forces in getting a reasonable process in place? Can we think of one pipeline with predictable outcomes?

view this post on Zulip Alexander Henket (Jun 11 2020 at 10:05):

For the record, this is the MVC list of HL7 systems:

  • 2.16.840.1.113883.5.1 Administrative gender
  • 2.16.840.1.113883.5.25 Confidentiality
  • 2.16.840.1.113883.5.1008 NullFlavor
  • 2.16.840.1.113883.5.111 Personal relationship
  • 2.16.840.1.113883.5.110 Role class
  • 2.16.840.1.113883.5.1070 substanceAdminSubstitution
  • 2.16.840.1.113883.5.1119 AddressUse
  • 2.16.840.1.113883.5.139 TimingEvent

view this post on Zulip Jose Costa Teixeira (Jun 11 2020 at 10:09):

does that include eventually

  1. adding other codesystems? e.g. MaritalStatus, or MedicinalProductGranularityLevel
  2. mapping the codes to national codes/extensions?

view this post on Zulip Alexander Henket (Jun 11 2020 at 10:12):

ehDSI is in control on what they add to their set. We only translate. The answer could be yes to more systems (HL7 or not)

Mappings is an awkward topic. The NCP is required to do so inbound/outbound, but while outbound is in the requirement specs, I'm told inbound is not. So we would receive SNOMED CT drug codes that we have no way of handling for because the mapping to G-Standard is not catered. This was the situation about a year ago. Not sure were that is now

view this post on Zulip Jose Costa Teixeira (Jun 11 2020 at 10:15):

Agree, mapping is dificult. I was thinking of mapping for the simple (?) ones like gender and marital status and address use

view this post on Zulip Jose Costa Teixeira (Jun 11 2020 at 10:15):

mapping for drug codes is something I would avoid (just listing what kind of codes exist is already a big task)

view this post on Zulip Alexander Henket (Jun 11 2020 at 10:15):

As for translation there are also roughly two routes:

  • translate only what's in the value sets
  • translate the underlying code system

Since the underlying code systems are really small (< 50 terms each) I see no reason to just translate what's in the value sets. E.g. about 80% of NullFlavor is in the ehDSI value set... a waste not to translate the remaining 4-5 codes

view this post on Zulip Jose Costa Teixeira (Jun 11 2020 at 10:16):

and your question is whether we should have a process, right?

view this post on Zulip Alexander Henket (Jun 11 2020 at 10:17):

mapping for drug codes is something I would avoid (just listing what kind of codes exist is already a big task)

We have a company that does IDMP mapping to our set for us. As for SNOMED CT: it appears that SNOMED CT is the lingua franca in European exchange, but internally we will never switch to SNOMED CT for medication.

view this post on Zulip Jose Costa Teixeira (Jun 11 2020 at 10:18):

same with IDMP, I think. It has a purpose for regulators, can help in prescriptions but we cannot map the codes to the ones we use.
But the Unicom project will handle that

view this post on Zulip Jose Costa Teixeira (Jun 11 2020 at 10:18):

But outside of meds, if it's about (reference) data governance processes, I think it's good to do so, and I'd like to join

view this post on Zulip Alexander Henket (Jun 11 2020 at 10:20):

and your question is whether we should have a process, right?

Yes. It seems reasonable to think that all countries translate HL7 systems and all could benefit from having the translations distributed by UTG. HTA/Vocab already said they are willing to work with us (NL) on this, but I think the case would be better if this route goes for all of us. Same process, same handling, same results. I fear that we over-ask vocab otherwise

view this post on Zulip Alexander Henket (Jun 11 2020 at 10:22):

And I also got the feeling most countries were not even considering bringing their results to a wider audience than the ehDSI use case which is a waste in my mind: so having a process is also about making it easy for countries who may feel that is 'too much work'

view this post on Zulip Christof Gessner (Jun 11 2020 at 12:59):

Hi @Alexander Henket "The eHDSI" is not controlling the translations. This is entirely the responsibility of the member states. And for HL7 it is under the control of the national HL7 Affiliate as per the Affiliate agreement. The Affiliate has the exclusive right for translation, they can delegate it to third partys with an appropriate contract. We had the topic on the IC agenda several times.

view this post on Zulip Christof Gessner (Jun 11 2020 at 13:00):

Also, the Affiliates will share their translations with HL7 International, as agreed. Under joint copyright.

view this post on Zulip Alexander Henket (Jun 11 2020 at 13:01):

Whoever creates those translations: they are not flowing to HL7 Org at all. For The Netherlands the creation process lies with Nictiz in the national terminology centre, but we fully cooperate with HL7 NL (Roel Barelds to be precise)

view this post on Zulip Alexander Henket (Jun 11 2020 at 13:02):

If you say translations are shared: what process does this follow?

view this post on Zulip Christof Gessner (Jun 11 2020 at 13:03):

"7.3.7 Upon their completion, translated versions of the HL7 Protocol Specifications and all other translated HL7 materials shall be promptly forwarded to HL7 International for publication to its members as Affiliate Material, subject to the provisions of section 8.3" in the Agreement

view this post on Zulip Alexander Henket (Jun 11 2020 at 13:04):

Has this ever been done? I don't know it has been

view this post on Zulip Christof Gessner (Jun 11 2020 at 13:05):

That's a good question, but it sounds like a good plan ;-)

view this post on Zulip Alexander Henket (Jun 11 2020 at 13:50):

It does sound like a plan, until you send spreadsheets, CodeSystems, txt files, and what not to Ted and he displays "does not compute"

view this post on Zulip Alexander Henket (Jun 11 2020 at 13:51):

Maybe affiliate stuff should be published in a terminology IG per affiliate like all the other IGs, hence management is fully in the hands of the affiliate and HL7 sort of has their hands free. How such an IG ties into UTG would be a relevant question

view this post on Zulip Giorgio Cangioli (Jun 11 2020 at 16:02):

Alexander Henket said:

Has this ever been done? I don't know it has been

never done as HL7 Italy... :blushing:

view this post on Zulip Giorgio Cangioli (Jun 11 2020 at 16:06):

but using the code system supplements it could be easier.. are they (i.e. language translations) already supported by UTG ?

view this post on Zulip Giorgio Cangioli (Jun 11 2020 at 16:09):

suggestion on how to proceed ?

view this post on Zulip Jens Villadsen (Jun 11 2020 at 16:45):

We are planning in DK to make use of supplements for code systems as part of the comming national ig

view this post on Zulip Alexander Henket (Jun 14 2020 at 19:47):

I think we should at least agree that CodeSystem Supplements (CSS) are the way to go. I don't remember is UTG was quite ready for them but Ted said it could work, and suspect that Grahame is called in if and when we actually start delivering

The next thing is probably figuring out what that means for further machinery:

  1. How does UTG know it is talking to the right delivery group(s). Does that involve paperwork of some sort if the delivery group is not the affiliate? Can only the affiliate interface with UTG for updates?

  2. What happens to the CSS. Are they incorporated as-is? Are they QA-ed by UTG? What tools do we have to QA locally? (saves everybody time if CSS if first time right)

  3. What to expect from publication? Do they just go into https://terminology.hl7.org/... or also in tx.fhir.org, other places? At what pace? I would expect a different pace from CSSs than from FHIR versions.

Does HL7 Europe have a role? Or should we just make it an IC action item?

view this post on Zulip Giorgio Cangioli (Jun 15 2020 at 13:25):

Alexander Henket said:

Does HL7 Europe have a role? Or should we just make it an IC action item?

I think it could be definitively an action promoted by HL7 EU ..

view this post on Zulip Giorgio Cangioli (Jun 15 2020 at 13:32):

If you want I can volunteer to contact Ted and Grahame, adding some of you in the email to contribute to the conversation.. .

view this post on Zulip Giorgio Cangioli (Jun 15 2020 at 13:35):

meanwhile, if we agree to proceed with Code system supplements, we can start working on the identified CSs and in the "worst" case publish them in a HL7 EU IG

view this post on Zulip Christof Gessner (Jun 15 2020 at 14:09):

IMHO the role of HL7 Europe in this context is: To make the options visible to the terminology people in the EU-Commission and in the Member States/Affiliates. I already pointed some persons to this thread here, hoping that we can arrive at decisions (e. g.: is CSS a potential way forward? any knowledge or technology required? etc.)


Last updated: Apr 12 2022 at 19:14 UTC