Stream: cimpl
Topic: Conflicting definitions
Kurt Allen (Sep 25 2019 at 22:58):
@Chris Moesel
(Really, I have not been storing these up just sp I can dump them all at once and ruin your day, really...)
I have a case where I have a Use with two namespaces in it, both of which define a Code element, and I getting the following error.
ERROR 11047: 'Resolution error: Found conflicting definitions for Code in multiple namespaces: fhir.observation,fhir.quantity '****
One Use is to define the parent class, and the other to define a member type. I can not use the full namespace and remove either of the two use's because the full namespace appears to be only partially implemented.
i.e. I cant say
ValueX[fhir.quantity.Quantity].System
and
Parent: fhir.observation.Observation
also returns compiel errors.
I really don't use either of these definitions, except in a context where it is obvious which one I mean. Is there a possible to ignore this error unless that code needs to reference a 'Code' where it is not in contect determinable which one we mean?
I.E. Code below is used only when referring to a Quantity, so the s/w could be able to determine the correct Code...
Kurt A.
Grammar: DataElement 6.0
Namespace: brr
Uses: fhir.observation, fhir.quantity
Entry: BreastRadiologyAbnormalityMaxLength
Parent: Observation
ValueX 1..1
ValueX only Quantity
ValueX[Quantity].System = "http://unitsofmeasure.org"
ValueX[Quantity].Code from UnitsOfLengthVS
Chris Moesel (Sep 26 2019 at 00:50):
Hi @Kurt Allen -- I think you identified the two potential approaches to fixing this... one would be adding support for the fully qualified names in those areas you found they are not supported. Another would be trying to determine which element it is through the context of where it is used (i.e., your ValueX[Quantity].Code example). Both of these require code changes in the CLI. The most immediate fix, of course, would be for you to change the name of one of them to something unique (if you need a fix now).
Chris Moesel (Sep 26 2019 at 00:52):
We now use Jira to track issues. I wonder if perhaps you could log this as a Jira issue? That would make it easier for us to track it and would allow you to track it as well. You can find our Jira here: https://standardhealthrecord.atlassian.net/projects/CIMPL/issues
You may have to sign up for a free account to log a bug.
Chris Moesel (Sep 26 2019 at 00:54):
Also, @Mark Kramer spent a lot of time on defining OBF and the mappings to FHIR so that most everything would work as needed. I'm curious why you have chosen to move away from OBF and write your own FHIR base elements and mappings? Is there a deficiency in OBF that we could fix there that would keep you from having to do all that work?
Kurt Allen (Sep 26 2019 at 13:24):
Hello @Chris Moesel We had some concerns raised vis-a-vis breast radiology profile that it was derived from US-Core and we wanted to see what these looked like working directly from the fhir resources.
For the short term I will just overload the name. Esp. with fields named 'code that makes more sense.
Chris Moesel (Sep 26 2019 at 13:30):
@Kurt Allen -- as you know, similar concerns were raised about mCODE at the Connectathon. We should circle with @Mark Kramer to see if he has plans to do a non-US-Core OBF.
In the mean time (or if he doesn't) -- it seems like you should be able to take the OBF source and:
1) Change any mappings from elements to US Core profiles just to map to the base resource instead
2) Remove/replace references to US Core extensions in the mapping files
3) Remove/replace US Core value sets in the CIMPL definition files
This would essentially maintain the structure and general mapping approach of OBF while removing the US-Core-centric aspects of it. It might be easier than trying to create new classes and mappings from the ground up.
Kurt Allen (Sep 27 2019 at 03:14):
@Mark Kramer Is this something you are thinking of doing?
Kurt Allen (Sep 27 2019 at 14:59):
@Chris Moesel I am getting some parse errors, and I cant find any indication of the file or line # where the error is. Any ideas on how I can track down the offending line? Unfortunately I made a log of changes all at once, and it would not be easy to back them all out and do them one by one to see where I made the booboo...
Kurt
INFO 05001: 'Starting CLI Import/Export'
During: shr-cli
INFO 01012: 'Using config file C:\Development\MITRE\cimpl\Fhir-BreastRadiologyReport\CIMPL\ig-breastRad-config.v4.json'
During: shr-text-input
ERROR 11015: 'token recognition error at: '/''
During: shr-text-input
Suggested Fix: This is usually a typo issue. Investigate keywords and missing colons around the specificed text input.
ERROR 11023: 'extraneous input '*' expecting {<EOF>, 'Abstract:', 'Element:', 'Entry:', 'Value', 'Property:', 'or', 'Group:', '_Entry', 'boolean', 'integer', 'string', 'decimal', 'uri', 'base64Binary', 'instant', 'date', 'dateTime', 'time', 'concept', 'oid', 'id', 'markdown', 'unsignedInt', 'positiveInt', 'xhtml', null, null, null, null}'
During: shr-text-input
Suggested Fix: This is usually a typo issue. Investigate spelling and keywords used around the specificied text input.
Kurt Allen (Sep 27 2019 at 15:18):
@Chris Moesel I found the problem, a file had a trailing '{asterix}/' in it (without a starting '/{asterix}').
(zulip wont let me use a asterix directly, so use your imagination)
But I had to
a) set log level to debug
b) find the last file that compiled properly in the output
c) open the next file in the directory and search for a compile error.
It would be really helpful if a log message was added detailing the file in which the error ocurred?
Thanks,
K
Kurt Allen (Sep 27 2019 at 20:07):
Hey @Chris Moesel
Re clean differential.
I am using the obf base classes (minus is core stuff), and I create an entry derived from Observation, and don't constrain Observation.basedOn. In the output json, I see the definition below.
The reason that the differential has a value for basedOn in it is because I guess shr-cli is constraining the target profile from (for instance) MedicationRequest to obf-MedicationRequest.
How can I stop that from happening, so we get a clean differential?
Kurt
{
"id": "Observation.basedOn",
"path": "Observation.basedOn",
"short": "Fulfills plan, proposal or order",
"type": [
{
"code": "Reference",
"targetProfile": [
"http://hl7.org/fhir/us/breast-radiology/StructureDefinition/obf-MedicationRequest",
"http://hl7.org/fhir/us/breast-radiology/StructureDefinition/obf-ServiceRequest",
"http://hl7.org/fhir/us/breast-radiology/StructureDefinition/obf-ProcedureRequest",
"http://hl7.org/fhir/us/breast-radiology/StructureDefinition/obf-ReferralRequest"
]
}
],
Chris Moesel (Sep 27 2019 at 20:28):
Hi @Kurt Allen
Re: log output for syntax errors, we can take a look as see if we can output more information (file and line #). I thought we did this before, but I may be mistaken, or it may have been mistakenly removed when we changed the log format.
Re: not wanting those profiles on the basedOn targets, you're using a CP file, right? If so, I think you want to have these in it:
Namespace: obf NP Namespace: obf.datatype NP
That says not to create profiles from any of the definitions in the obf or obf.datatype namespaces.
Kurt Allen (Sep 27 2019 at 22:30):
Hi @Chris Moesel
I added the two namesapce lines as per you note (I removed those when I was playing around - sorry should have remembered).
I have modified the obf files to remove all references to US-Core (i.e. I may have introduced an error)
When I added them back in, I get the error below. I have no idea what this error is trying to tell me :-)
K
INFO 03007: 'Exporting FHIR using target: FHIR_R4'
During: FHIR Export
Target Class: FHIR_R4
ERROR 13064: 'Could not find FHIR element for content profile rule with path '
During: FHIR Export
Class: MedicationDispense
Target Class: DomainResource
Kurt Allen (Sep 27 2019 at 22:31):
P.S. This will keep until Monday.... :-)
Kurt Allen (Sep 28 2019 at 13:13):
Update: Tried reverting to the shr-spec files that are checked in (tried both master - sep 5 and most recent version). Got same error. Don't think problem is caused by any changed I made to obf files.
Chris Moesel (Sep 30 2019 at 13:42):
Hmmm... @Mark Kramer -- have you run into this?
Mark Kramer (Sep 30 2019 at 15:53):
@Kurt Allen can you check your content profile file for any mention of MedicationDispense? Perhaps the namespace might be incorrect? Or MedicationDispense is not defined in the CIMPL files?
Kurt Allen (Sep 30 2019 at 20:28):
@Mark Kramer The only references are from shr-spec.
A) obf_finding.txt line 332 (ObservationPartOf) and
B) obf-medication.txt LINE 133 & 197.
Nick Freiter (Oct 08 2019 at 16:17):
@Kurt Allen Hello, I'm a developer working on CIMPL with Chris. That "Error 13064" that you are seeing was actually a bug, and we are fixing it now. The bug causing the error message did not cause any unexpected functionality, so you can just ignore that error message until our fix is published.
As for directly using MedicationRequest instead of obf-MedicationRequest, you do want to use the NP flag that Chris mentioned, but you likely want to be more careful about how you apply it. In the example Chris showed, the NP flag will prevent profiles from being made for definitions in the obf or obf.datatype namespaces, but it will also prevent profiles from being made for definitions that inherit from definitions in obf or obf.datatype. So you probably do not want to NP all of obf, since you have definitions that inherit from definitions in obf. You can apply the NP flag at a definition specific level instead of applying it to the entire namespace in the following way:
Namespace: obf // Don't apply NP at this level MedicationRequest: NP // apply NP at this level ServiceRequest: NP ProcedureRequest: NP ReferralRequest: NP // and so on for definitions that you wish to not have a profile for
This gives you the ability to pick and choose which definitions that you want to apply the NP flag to.
Last updated: Apr 12 2022 at 19:14 UTC
