# Findings: "Transform openEHR to FHIR Questionnaire" **Category:** [LinkEHR](https://discourse.openehr.org/c/linkehr/38) **Created:** 2020-04-27 08:22 UTC **Views:** 3279 **Replies:** 29 **URL:** https://discourse.openehr.org/t/findings-transform-openehr-to-fhir-questionnaire/614 --- ## Post #1 by @Kenneth_Myhra Here are some of my findings from playing with the "Transform openEHR to FHIR Questionnaire" feature in LinkEHR: * enableBehaviour should be enableBehavior * item.linkId is not always unique * DV_QUANTITY is not properly transformed. item.type is missing * DV_QUANTITY missing unit * For quantity data types I have been using an extension (STU3), that might have been moved to code in R4 version, but I can't confirm that * All text fields are converted to item.type = "text", for some of them it would make more sense to use item.type = "string" --- ## Post #2 by @yampeku Hello Kenneth, Just released a new version, which deals with domain types (one being DvQuantity). I haven't seen any example with units, so probably is not yet core. Will have a look to the extension. Do you have a link to it? For the text vs string, do you think there could be some kind of decision tree to choose one or the other? (e.g. if we have answerOption it should be a string). I'll have a look at the enableBehaviour & linkid issue --- ## Post #3 by @Kenneth_Myhra Example with DV_QUANTITY and ``: https://arketyper.no/ckm/templates/1078.60.848/export Link to unit extension: http://hl7.org/fhir/extension-questionnaire-unit.html Representation in FHIR STU3: For text vs string I was hoping there was some kind of distinction between small vs large fields in the .opt, but I think there isn't? --- ## Post #4 by @yampeku [quote="Kenneth_Myhra, post:3, topic:614"] For text vs string I was hoping there was some kind of distinction between small vs large fields in the .opt, but I think there isn’t? [/quote] Maybe leaving string for DV_TEXT and text for things like DV_PARAGRAPH is an option --- ## Post #5 by @Kenneth_Myhra That seems to make sense. Just so you know, my openEHR knowledge is currently very limited so I am not very aware of the different data types and/or structures. --- ## Post #6 by @yampeku [quote="Kenneth_Myhra, post:3, topic:614"] http://hl7.org/fhir/StructureDefinition/questionnaire-unit [/quote] BTW, how do you deal with having unit alternatives? --- ## Post #7 by @Kenneth_Myhra [quote="yampeku, post:6, topic:614"] BTW, how do you deal with having unit alternatives? [/quote] I don't think we have had such a use case yet --- ## Post #8 by @siljelb DV_PARAGRAPH is deprecated (https://specifications.openehr.org/releases/RM/latest/data_types.html#_dv_paragraph_class). The length of text elements are left up to the implementers when we construct archetypes and templates, it's not possible (or IMO desirable) to do it in the information model. I'm not sure I understand the significance of the text/string division? I've found the definition of String, but I'm struggling to find Text... --- ## Post #9 by @Kenneth_Myhra [quote="yampeku, post:6, topic:614"] BTW, how do you deal with having unit alternatives? [/quote] This seems to be the proper way for handling units on Quantity in R4, also example has unit alternatives ``` ``` --- ## Post #10 by @Kenneth_Myhra [quote="siljelb, post:8, topic:614"] I’m not sure I understand the significance of the text/string division? I’ve found the definition of String, but I’m struggling to find Text… [/quote] http://hl7.org/fhir/valueset-item-type.html#expansion string - Question with a short (few words to short sentence) free-text entry answer (valueString). text - Question with a long (potentially multi-paragraph) free-text entry answer (valueString). This means that our form rendrer will render a text data type as a textarea, and a string a an input --- ## Post #11 by @siljelb Ah, now I understand. I think this would need to be the choice of the implementer, so a UI choice applied after the initial conversion in this case. --- ## Post #12 by @yampeku can also be a choice in the generation, however would be or all texts or all strings :sweat_smile: --- ## Post #13 by @yampeku From this example I think it should be ok to put in the code the binding to the original openEHR object, such as ``` ``` --- ## Post #14 by @Kenneth_Myhra [quote="yampeku, post:13, topic:614"] From this example I think it should be ok to put in the code the binding to the original openEHR object, such as [/quote] Like this? --- ## Post #15 by @yampeku I mean, instead of the loinc bindings, treat the original openEHR object as what's giving the meaning. The units part with answerOption I think it's ok --- ## Post #16 by @Kenneth_Myhra Is there some common unique reference to the Code System other than `openEHR-EHR-OBSERVATION.laboratory_test_result.v1`? http://hl7.org/fhir/datatypes-definitions.html#Coding.system > The URI may be an OID (urn:oid:...) or a UUID (urn:uuid:...). OIDs and UUIDs SHALL be references to the HL7 OID registry. Otherwise, the URI should come from HL7's list of FHIR defined special URIs or it should reference to some definition that establishes the system clearly and unambiguously. --- ## Post #17 by @yampeku I've put that under an uri such as "http://openehr.org/openEHR-EHR-OBSERVATION.laboratory_test_result.v1" in the past. In fact, this openehr base uri is also configurable --- ## Post #18 by @yampeku [quote="Kenneth_Myhra, post:1, topic:614"] enableBehaviour should be enableBehavior [/quote] This attribute was removed completely in today's version BTW --- ## Post #19 by @Kenneth_Myhra Noticed that a few of the ValueSet generated from this OPT: https://arketyper.no/ckm/templates/1078.60.876/opt is missing code values I've added two examples generated from that OPT, one where the code values are included, and one where they are missing Example of ValueSet missing code values:

Value set *Test name (en). *The name of the imaging examination or procedure performed. (en)

Developed by: openEHR community

Generated with LinkEHR

This value set includes codes from terminology NCRP

  • SSC0AA:
Example of ValueSet not missing code values:

Value set Er det noen tilstander tilstede?. Tilstedeværelse av relevante tilstander.

Developed by: openEHR community

Generated with LinkEHR

This value set includes codes from archetype openEHR-EHR-COMPOSITION.report.v1 internal terminology

  • at0031: Tilstede
  • at0032: Fraværende
  • at0033: Ukjent
--- ## Post #20 by @yampeku Thanks, seems related to external terminologies, I'll try it with your example :smiley: --- ## Post #21 by @yampeku Fixed the problem 😀 Will be corrected in next version --- ## Post #22 by @yampeku Just released a new version including fixes to all the above issues :grin: --- ## Post #23 by @Kenneth_Myhra Thanks, liked the new features like choosing between text and string for DV_TEXT! Tried a new export and sorry to say still some issues. Using the same OTP I posted previously in the thread: https://arketyper.no/ckm/templates/1078.60.876/opt I haven't had time for a thorough scan of the generated Questionnaire, anyway listing some of my findings under. This part is missing sub items which is in the OTP, there are also other parts of the Questionnaire which are missing sub items: ``` ``` These items are missing the type attribute (could be the same is true elsewhere in the Questionnaire as well): ``` ``` --- ## Post #24 by @yampeku Thanks! will review it as soon as possible --- ## Post #25 by @yampeku First one is easily fixable, I forgot to specify how ADMIN_ENTRY must be traversed :see_no_evil: edit: second one are objects under "name" attribute being generated, which probably shouldn't (it already uses terminology part of the OPT to put the names in the questionnaire object) --- ## Post #26 by @Kenneth_Myhra Does that mean both of them are easily fixable? :slight_smile: --- ## Post #27 by @yampeku Think so :D edit: Squashing the second one right now, pure EVENT classes were not considered yet --- ## Post #28 by @yampeku Just released a new version solving these issues @Kenneth_Myhra In principle there are no more missing types as the number of type tags equals the linkid ones :) --- ## Post #29 by @erik.sundvall [quote="yampeku, post:17, topic:614, full:true"] I’ve put that under an uri such as “http://openehr.org/openEHR-EHR-OBSERVATION.laboratory_test_result.v1” in the past. In fact, this openehr base uri is also configurable [/quote] If we would later go by one of the URN suggestions in [DV_EHR_URI-related Issues - Specifications - Confluence (atlassian.net)](https://openehr.atlassian.net/wiki/spaces/spec/pages/786956289/DV+EHR+URI-related+Issues) and register the openehr URN, then that uri example could instead be `urn:openehr:archetype:openEHR-EHR-OBSERVATION.laboratory_test_result.v1` **Context**: We are at Karolinska University hospital currently starting to look at two-way conversions between openEHR templates and FHIR Questionnaires for some use cases where we need to use some already available form services. We thus found this thread interesting. If anybody has done more in this area after the posts above, please share your experiences. --- ## Post #30 by @Kevin_Mayfield Link to a post I made on a similar topic https://discourse.openehr.org/t/openehr-and-fhir-ukcore/2564/17?u=kevin_mayfield --- **Canonical:** https://discourse.openehr.org/t/findings-transform-openehr-to-fhir-questionnaire/614 **Original content:** https://discourse.openehr.org/t/findings-transform-openehr-to-fhir-questionnaire/614