Stream: genomics/committers
Topic: warning: multiple matching profiles among choices
Jamie Jones (Sep 12 2019 at 18:55):
Interesting error (strength="warning") we are currently getting on Observation.derivedFrom instances in examples:
Found multiple matching profiles among choices: ; [http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/obs-haplotype, http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/obs-variant]
In particular, Haplotype can be derived from either a Haplotype or a Variant, and the validator seems to get confused because they are both Observations. That is, even if we are declaring the "derivedFrom" resource as obs-variant, the validator seems to be picking haplotype and validating it against that structureDef.--We later get the error,
Expected fixed CodeableConcept not found for system: http://loinc.org code: 84414-2 display: null - Issues: [ValidationMessage[level=ERROR,type=VALUE,location=Bundle.entry[9].resource.code.coding.code,message=Value is '69548-6' but must be '84414-2']]
Where the haplotype is 84414-2 and variant is 69548-6.
I saw another thread about this, will try and link here/follow-up
Jamie Jones (Sep 12 2019 at 18:56):
Similar errors appear for genotypes which can be derived from either haplotypes or variants
Kevin Power (Sep 26 2019 at 17:53):
@James Jones -- just checking on this, as we are still getting these warnings. Did you ever find another thread on this topic?
Jamie Jones (Sep 26 2019 at 18:00):
This is "working as intended" due to the other errors
Kevin Power (Sep 26 2019 at 18:02):
Heh heh, ok. Which other errors, or do you know?
Jamie Jones (Sep 26 2019 at 18:02):
The validator realizes the reference could be multiple profiles so test it against all options. If one passes, no errors or warning is displayed. If all fail (current case due to LOINC value set errors) then the warning and relevant errors are displayed.
Jamie Jones (Sep 26 2019 at 18:02):
From Lloyd, Q4 Wednesday, tried to get that into the notes
Kevin Power (Sep 26 2019 at 18:15):
Matching multiple error class should go away after Tx server fix
Bet that is it? I was sort of wondering what that meant, but now it makes perfect sense. :slight_smile: Thanks @James Jones
Jamie Jones (Oct 05 2019 at 02:27):
Think we may have to declare this differently on the spreadsheets. Getting errors for the other profile types even when the derivedFrom resource does validate against one of the matched profiles.
Jamie Jones (Oct 05 2019 at 02:28):
(validates with warnings and not errors, that is)
Kevin Power (Oct 05 2019 at 02:55):
Have you tried anything different?
Jamie Jones (Oct 05 2019 at 02:59):
Well, I tried just having it say "Observation|MolecularSequence" and putting the relevant profiles in the definition ... that worked
Jamie Jones (Oct 05 2019 at 03:00):
we may need to mirror how genomics-report and grouper do their references rather on individual lines rather than using | in one line
Kevin Power (Oct 05 2019 at 03:01):
Whatever works :+1:
Jamie Jones (Oct 05 2019 at 03:44):
Well, not forcing the validator to (very strictly) check the referenced profiles match is one way that works. If we want to mirror the slicing on hasMember for grouper or result for genomic-report we have some issue as most of these derivedFrom references can also refer to a MolecularSequence, which fails to have a code and can't be discriminated under the resolve().code.@pattern
Bret H (Oct 05 2019 at 04:35):
Sorry. I am ignorant. Why would MolecularSequence, a Resource, need a code?
Jamie Jones (Oct 05 2019 at 12:32):
Slicing derivedFrom on resolve().code requires all the profiles we list in the slice to have codes. There's probably a better solution to define the references, and I'm not sure we need to slice here, especially on code, but the previous approach causes errors
Kevin Power (Oct 05 2019 at 13:50):
Maybe @Lloyd McKenzie has a recommendation?
Lloyd McKenzie (Oct 05 2019 at 19:49):
You could slice by type, then by code
Kevin Power (Oct 05 2019 at 21:17):
So it would “short circuit” and not look for code on MolecularSequence since it is a different type?
Lloyd McKenzie (Oct 05 2019 at 22:16):
I think it would only look for code if there is more than one slice for the same type. That's what should happen
Bret H (Oct 06 2019 at 02:50):
makes sense to me now. I think we'd need to to do type first then by code.
Kevin Power (Oct 06 2019 at 13:02):
Ok I can try this Monday unless someone else beats me to it.
Kevin Power (Oct 07 2019 at 16:22):
We talked about it on the call, but to update here: I did try a variety of approaches, and none have worked yet. I tried defining the discriminator like this in the spreadsheet (I am playing around with Genotype):
resolve(), resolve().code.@pattern
Then I list variant, haplotype, and MolecularSequence as different slices. It builds fine, and the profile page looks right, but the examples do not validate appropriately. We get the error:
Unable to resolve discriminator in definitions: code
It just seems like having MolecularSequence in there causes problems. For a test, I took it out, and the error above goes away. So, it doesn't seem like it short cuts, and still looks for a 'code' on MolecularSequence. @Lloyd McKenzie says he has seen this work before, so I am just not doing something right.
Any feedback from anyone is welcome at this point.
Kevin Power (Oct 07 2019 at 16:48):
Well crap - never mind. We don't need to specify MolecularSequence, because it is listed in the Observation profile for derivedFrom already (meaning any Observation can already be derivedFrom() a MolecularSequence. When I took it out before, I thought I was seeing a different error come up, but turns out I was wrong.
Jamie Jones (Oct 07 2019 at 16:53):
If we don't list it on the profile then aren't we constraining the choice of references to just the Observations?
Kevin Power (Oct 07 2019 at 16:55):
I thought the same thing, and I thought I say an error that said that. However, it doesn't seem that way. We have examples (CG-IG-HLA-FullBundle-01.xml) that deriveFrom() MolecularSequence, and it seems to validate just find if I take it out.
Jamie Jones (Oct 07 2019 at 17:01):
Not even a suppressed error like we saw on call today for implications?
Kevin Power (Oct 07 2019 at 17:03):
Ahhh, OK. It turns into a 'informational' message:
Bundle/CG-IG-HLA-FullBundle-01: Bundle.entry[9].resource.derivedFrom[0] information This element does not match any known slice for the profile http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/haplotype
Kevin Power (Oct 07 2019 at 17:04):
Turns out that example has a Haplotype, not a Genotype. And since I was only playing around with Genotype, I didn't see this informational message until I applied my "fix" to all of our profiles.
Kevin Power (Oct 07 2019 at 17:05):
This still feels better to me, at least for now?
Kevin Power (Oct 07 2019 at 17:07):
I will push up my change and let everyone take a look (if you can make heads or tails of the Diff) ((yet another way doing this via spreadsheets is tough))
Jamie Jones (Oct 07 2019 at 17:36):
I'll review it today for sure
Kevin Power (Oct 07 2019 at 18:03):
Just tested putting a resource in derivedFrom() (Patient in this case) that is NOT valid at all, and got an error. Not a surprise, but that does indicate the validator realizes that a derivedFrom() to MolecularSequence is 'valid' - but since we defined slices, it is just telling us it doesn't match one that we defined.
Kevin Power (Oct 07 2019 at 18:18):
Changes pushed up.
Kevin Power (Oct 07 2019 at 19:47):
Also, I had forgotten about the 'suppressed' warnings that we discussed today on the call. I just removed all of the warnings/info messages from the src\ignoreWarnings.txt file, and rebuilt. Did not add any new error, warning, or info messages to the QA that I can see.
Jamie Jones (Oct 07 2019 at 20:10):
Should we consider adding new 'ignoreWarnings' here for the items identified as ok?
Kevin Power (Oct 07 2019 at 20:14):
I figure we will see if that needs to happen during publishing
Jamie Jones (Oct 07 2019 at 21:24):
change looks good to me. Can consider better guidance in the future but getting a warning from someone sending a Molecular sequence rather than one of the profiles we defined in the IG seems like pretty good practice for now.
Bret H (Oct 08 2019 at 17:25):
sorry: what's the text for the warning? Best practice warning? thanks!
Jamie Jones (Oct 08 2019 at 17:29):
Bundle/CG-IG-HLA-FullBundle-01: Bundle.entry[9].resource.derivedFrom[0] information This element does not match any known slice for the profile http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/haplotype
Jamie Jones (Oct 08 2019 at 17:30):
it's provided as 'information' severity
Bret H (Oct 08 2019 at 17:33):
okay. Thanks. I think I got it. Currently, when Molecular Seq is used you get the text you sent. Right? This is going to drive developers nuts. But I favor a planned technical correction - it needs to not error if Molec Seq is appropriate. If possible keep working at it. I wish I was more helpful and had a solution. You all have done marvelous with the problems to date.
Bret H (Oct 08 2019 at 17:33):
Maybe now is the point at which to abandon the Spreadsheet as the point of truth and edit the profile directly? But that is in your hands, cause you all are using it.
Kevin Power (Oct 08 2019 at 17:39):
We need to evaluate the new IG template coming out soon, and move in that direction. Will have to see where that leads us in editing the profiles (XML, spreadsheets, online tool, etc ...)
Bob Milius (Apr 10 2020 at 03:06):
Is there anything new on this? I'm trying to profile Haplotype to add derivedFrom to reference a profile of MolecularSequence, and am getting similar errors (no code). Any idea how I should set the discriminator path for this slice?
Bob Milius (Apr 10 2020 at 03:22):
Even if I set the discriminator path to resolve().type in my profile of Haplotype, I keep getting a build error
Slicing rules on differential (pattern:resolve().type (/open) "reference HLA molecular sequence") do not match those on base (pattern:resolve().code (/open)) - disciminator @ Observation.derivedFrom (http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/haplotype)
So it looks like it's first getting the discriminator from Haplotype and that interfers with the one I'm creating in my profile of Haplotype.
Jamie Jones (Apr 10 2020 at 03:23):
Error? Or informational warning
Bob Milius (Apr 10 2020 at 03:24):
build stops with a stack dump
Bob Milius (Apr 10 2020 at 03:32):
If I use resolve().code, it builds fine, but I get an error when I try to add a slice for a profile of MolecularSequence (makes sense, MS doesn't have a code). If I change it to resolve().type, then I get a stack dump during the build.
Bob Milius (Apr 10 2020 at 14:32):
I just asked about this in the shorthand stream
https://chat.fhir.org/#narrow/stream/215610-shorthand/topic/changing.20derivedFrom.20path.20from.20parent
Kevin Power (Apr 10 2020 at 14:44):
Good luck @ Bob Milius - I remember beating my head on a wall for a long time on this one. I hope you can find a good answer :slight_smile:
Patrick Werner (Apr 10 2020 at 18:11):
@ Bob Milius to me this sounds like the shorthand framework overwrites the original discriminator somehow (or this is a Validator/Publisher bug). Could you share the created profile?
Bob Milius (Apr 11 2020 at 04:18):
I think I've found a solution. I saw this thread
https://chat.fhir.org/#narrow/stream/179177-conformance/topic/Validator.20and.20slicing
and Rob Hausam suggested this
<slicing>
<discriminator>
<type value="profile"/>
<path value="$this.resolve()"/>
</discriminator>
<rules value="open"/>
</slicing>
I tested this and it behaved as I wanted. So, would it be possible to create a technical correction of our IG to change the derivedFrom discriminator type and path to be like this? Then I could create profiles of the CG profiles and have derivedFrom slices for references other than Observation.
Bob Milius (Apr 11 2020 at 04:20):
@Patrick Werner I'll post SDs later this weekend.
Kevin Power (Apr 11 2020 at 12:10):
This is reminding me that I need to study up on slicing again :grinning:
Did you try Grahame’s suggestion on IG creation channel?
discriminator = type + pattern
Bob Milius (Apr 11 2020 at 12:40):
I didn't see that. I'm not sure what that looks like in a SD
Bob Milius (Apr 11 2020 at 13:05):
I tried setting
<slicing>
<discriminator>
<type value="pattern"/>
<path value="type"/>
</discriminator>
<rules value="open"/>
</slicing>
to create a named slice of derivedFrom in a profile of Observation. But I get an error in the qa.html when it validates an example:
Could not match discriminator ([type]) for slice Observation.derivedFrom:hla-sequence in profile http://example.org/ig/test/StructureDefinition/hla-allele3 - the discriminator [type] does not have fixed value, binding or existence assertions
Rob's suggestion worked for me, and didn't limit the kinds of profiles I can create slices for.
Bob Milius (Apr 11 2020 at 15:11):
I uploaded a test ig to http://fhir.b12x.org/ig/test/
There are no errors or warning in the qa.html though there are information msgs re some of the examples.
Take a look at the snapshot of hla-allele-obs2 profile. It contains two derivedFrom named slices, one for a profile of Observation, and the other for a profile for MolecularSequence. The former slice (named hla-allele) was created in this profile, and the latter slice (named hla-sequence) was created in the parent of this profile.
You can also see examples of each profile in the IG.
Patrick Werner (Apr 14 2020 at 10:29):
finally got some time for this:
Discriminating by profile is an anti pattern and quite dangerous. The problem here is that slicing on profiles relies on declaring the profile in meta. In our use-cases we can't assume that everyone fills meta.profile. (Our lab e.g. doesn't atm) but still complies to our IG.
Patrick Werner (Apr 14 2020 at 10:30):
So i would advise strongly against the usage of a profile discriminator.
Patrick Werner (Apr 14 2020 at 10:31):
It should be possible to add another discriminator in your derived profile. I assume this is also could be a FSH issue. Do you have a snapshot of a your haplotype profile which adds a second discriminator type?
Bob Milius (Apr 14 2020 at 13:43):
when I add add a second discriminator that isn't a subset of code, then the igpublisher crashes with a stack dump.
I asked the question on the shorthand stream. Mark Kramer doesn't think it's possible.
https://chat.fhir.org/#narrow/stream/215610-shorthand/topic/changing.20derivedFrom.20path.20from.20parent
Bob Milius (Apr 14 2020 at 13:51):
Here's the publisher crash error I get:
Caused by: org.hl7.fhir.exceptions.DefinitionException: Slicing rules on differential (pattern:type (/open) "reference HLA molecular sequence") do not match those on base (pattern:resolve().code (/open)) - disciminator @ Observation.derivedFrom (http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/haplotype)
Here's the StructureDefinition that caused it:
{
"resourceType": "StructureDefinition",
"id": "hla-allele-haplotype",
"url": "http://example.org/ig/test/StructureDefinition/hla-allele-haplotype",
"version": "0.1.0",
"name": "MyHaplotype",
"title": "HLA Allele profile of Haplotype",
"status": "active",
"description": "HLA Allele profile of haplotype",
"fhirVersion": "4.0.1",
"mapping": [
{
"identity": "v2-cg-results",
"uri": "http://unknown.org/V2-CG-Results",
"name": "V2-CG-Results"
},
{
"identity": "workflow",
"uri": "http://hl7.org/fhir/workflow",
"name": "Workflow Pattern"
},
{
"identity": "sct-concept",
"uri": "http://snomed.info/conceptdomain",
"name": "SNOMED CT Concept Domain Binding"
},
{
"identity": "v2",
"uri": "http://hl7.org/v2",
"name": "HL7 v2 Mapping"
},
{
"identity": "rim",
"uri": "http://hl7.org/v3",
"name": "RIM Mapping"
},
{
"identity": "w5",
"uri": "http://hl7.org/fhir/fivews",
"name": "FiveWs Pattern Mapping"
},
{
"identity": "sct-attr",
"uri": "http://snomed.org/attributebinding",
"name": "SNOMED CT Attribute Binding"
}
],
"kind": "resource",
"abstract": false,
"type": "Observation",
"baseDefinition": "http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/haplotype",
"derivation": "constraint",
"differential": {
"element": [
{
"id": "Observation.value[x]",
"path": "Observation.value[x]",
"min": 1
},
{
"id": "Observation.valueCodeableConcept",
"path": "Observation.valueCodeableConcept",
"patternCodeableConcept": {
"coding": [
{
"system": "http://glstring.org"
}
]
}
},
{
"id": "Observation.derivedFrom",
"path": "Observation.derivedFrom",
"slicing": {
"discriminator": [
{
"type": "pattern",
"path": "type"
}
],
"rules": "open",
"description": "reference HLA molecular sequence"
}
},
{
"id": "Observation.derivedFrom:hla-sequence",
"path": "Observation.derivedFrom",
"sliceName": "hla-sequence",
"type": [
{
"code": "Reference",
"targetProfile": [
"http://example.org/ig/test/StructureDefinition/hla-molecularsequence"
]
}
]
},
{
"id": "Observation.component",
"path": "Observation.component",
"min": 1
},
{
"id": "Observation.component:gene-studied",
"path": "Observation.component",
"sliceName": "gene-studied",
"min": 1,
"max": "1",
"mustSupport": true
}
]
}
}
Patrick Werner (Apr 14 2020 at 13:54):
hmm multiple discriminators should work.
Patrick Werner (Apr 14 2020 at 13:54):
i'll try to investigate this week.
Patrick Werner (Apr 14 2020 at 13:57):
From the FHIR spec: If a discriminator for an element is declared in a parent profile, child profiles referencing that element:
SHALL include all the same discriminators
MAY add additional discriminators
Bob Milius (Apr 14 2020 at 14:02):
I'm guessing the 'additional discriminators' have to be additional qualifiers to the parent (subsumed?). So not only obs.code, but perhaps obs.component as well.
Bob Milius (Apr 14 2020 at 14:43):
@Patrick Werner how do you validate a resource instance against a profile if you don't have meta.profile in the resource?
Jamie Jones (Apr 14 2020 at 14:47):
You can validate any instance against any profile--the meta is a shorthand for that but you could have a server require all sequences validate against profile XX, etc, or have it do whatever logic is required to determine which profiles to check it against
Bob Milius (Apr 14 2020 at 15:18):
@Jamie Jones can you show me a command line example? I know I can use -ig [source] option, but if the resource doesn't have the meta.profile how does it know which StructureDefinition to validate against? I assume it would just default to validating against the base resource (e.g., Observation). I just tried this before and after commenting out meta.profile and I get different validation errors/warnings
java -jar org.hl7.fhir.validator.jar genotype-example.xml -ig "http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/genotype"
Patrick Werner (Apr 14 2020 at 16:07):
The cli validator can't do that. But in our hapi we have implemented an interceptor checking all incoming DR against our profiles
Patrick Werner (Apr 14 2020 at 16:07):
Discriminating with a value which is always there (like code & type) is better. Even if a a MolSeq claims to comply to a profile, you would first have to validate it.
Patrick Werner (Apr 14 2020 at 16:09):
If you look at types and codes, this gets a lot easier. I think just adding type as a discriminator in the differential should be sufficient.
Patrick Werner (Apr 14 2020 at 16:09):
I assume the Validator has a bug
Patrick Werner (Apr 14 2020 at 16:10):
Will check that, we then should bring this to the conformance stream.
Kevin Power (Apr 14 2020 at 16:15):
You can tell the validator to validate against a profile: https://confluence.hl7.org/display/FHIR/Using+the+FHIR+Validator#UsingtheFHIRValidator-Whattovalidateagainst
The -profile parameter is the canonical URL for the profile you wish to validate against. This is usually clearly specified on the page where the profile is published. If the profile you specify has not been loaded through one of the implementation guides, the validator will try and load it directly from the canonical url, but it's better to load it with an -ig parameter first.
Patrick Werner (Apr 14 2020 at 16:26):
ah right!
Bob Milius (Apr 14 2020 at 16:53):
re slicing on MolecularSequence.type, I notice that it isn't required (0..1). Does that matter?
Maybe a better option would be to slice on MS.coordinateSystem (1..1)? (if we can figure out how)
Kevin Power (Apr 14 2020 at 16:58):
OK, maybe I am confused, but I don't think we are talking about MolecularSequence.type (as in attribute on the resource named 'type'), I think 'type' means the "Discriminator processing type" of type (way to many 'types' there :slight_smile:)
https://www.hl7.org/fhir/profiling.html#discriminator
Each discriminator is a pair of values: a type that indicates how the field is processed when evaluating the discriminator, and a FHIRPath expression that identifies the element in which the discriminator is found. There are five different processing types for discriminators
value The slices have different values in the nominated element.
exists The slices are differentiated by the presence or absence of the nominated element.
pattern The slices have different values in the nominated element, as determined by testing them against the applicable ElementDefinition.pattern[x].
type The slices are differentiated by type of the nominated element.
profile The slices are differentiated by conformance of the nominated element to a specified profile. Note that if the path specifies .resolve() then the profile is the target profile on the reference. In this case, validation by the possible profiles is required to differentiate the slices.
Bob Milius (Apr 14 2020 at 17:05):
Okay, Im confused too. I think right now discriminator.type = pattern, and discriminator.path= resolve().code. So I thought the code was for Observation.code. Maybe I'm wrong. I thought we were considering adding/changing path to resolve().type which would be a resource with a type element. I'm don't know much about fhirpath, so I could easily be wrong.
Patrick Werner (Apr 14 2020 at 19:14):
the code is [Resource].code. So every resource which is allowed in derived will be checked for code for the slice matching.
Patrick Werner (Apr 14 2020 at 19:14):
MolSeq doesnt has code. Thats why there is a runtime failure
Patrick Werner (Apr 14 2020 at 19:15):
And not a compile time failure
Patrick Werner (Apr 14 2020 at 19:16):
For Molseq we could add a type based slicing. Type equals the Name of a Resource here.
Patrick Werner (Apr 14 2020 at 19:18):
so it would need an additional discriminator: discriminator.type = typeand discriminator.path = $this.resolve()
Patrick Werner (Apr 14 2020 at 19:19):
disclaimer: slicing is still puzzles me a lot of times, and i'm not 100% sure.
Patrick Werner (Apr 14 2020 at 19:20):
@ Bob Milius you did try that already and got the error from the validator / IG creator right?
Bob Milius (Apr 14 2020 at 19:23):
No, I tried discriminator.type=pattern (or value) and discriminator.path = resolve().type
I'll try what you suggested.
Bob Milius (Apr 14 2020 at 19:23):
What does a json snippet look like for multiple discriminators?
Kevin Power (Apr 14 2020 at 19:24):
https://www.hl7.org/fhir/elementdefinition-definitions.html#ElementDefinition.slicing.discriminator
Kevin Power (Apr 14 2020 at 19:24):
It is a 0..*
.... discriminator Σ 0..* Element Element values that are used to distinguish the slices
....... type Σ 1..1 code value | exists | pattern | type | profile ---- DiscriminatorType (Required)
....... path Σ 1..1 string Path to element value
Bob Milius (Apr 14 2020 at 19:56):
so, you're suggesting something like this slicing? The first matches the parent (STU1), the second for the molseq?
{
"id": "Observation.derivedFrom",
"path": "Observation.derivedFrom",
"slicing": {
"discriminator": [
{
"type": "pattern",
"path": "resolve().code"
},
{
"type": "type",
"path": "$this.resolve()"
}
],
"rules": "open",
}
}
Patrick Werner (Apr 14 2020 at 19:58):
i‘m not 100% sure if the $this is needed. Maybe resolve() without the this is correct
Patrick Werner (Apr 14 2020 at 19:59):
but for the rest yes. So if you are deriving from our haplotype, only the type slicing has to be added. The resulting snapshot should then contain both.
Bob Milius (Apr 14 2020 at 20:43):
I tried different variations on this, and keep getting stack dumps from the publisher when trying to generate the snapshot. But I may be doing something wrong. If someone can show me an example profile whose parent is one of the observation profiles in our IG that adds a molseq to derivedFrom, I would be grateful.
Kevin Power (Apr 14 2020 at 21:13):
I am totally shooting in the dark here, but if you don't derive from the genomics-reporting Haplotype (as a test) does it still stack dump? Did you try to re-order the discriminators?
Bob Milius (Apr 14 2020 at 21:26):
I'll test that. In my example above I was able to use type=profile, and path=$this.resolve() on a profile for Observation and that worked for me (that profile being a parent for another profile). But that's not a good solution for Patrick's use case.
Patrick Werner (Apr 15 2020 at 13:15):
i think i did it: MyHaplotype.StructureDefinition.json
Patrick Werner (Apr 15 2020 at 13:15):
Derived from haplotype and adding a type slicing
Patrick Werner (Apr 15 2020 at 13:16):
I can validate this profile without getting errors.
Patrick Werner (Apr 15 2020 at 13:16):
"slicing": { "discriminator": [ { "type": "type", "path": "$this" } ], "rules": "open" }
Patrick Werner (Apr 15 2020 at 13:17):
found horrible bugs while doing this (probably in Forge):
Patrick Werner (Apr 15 2020 at 13:17):
https://chat.fhir.org/#narrow/stream/179177-conformance/topic/Context.20for.20Normative.20Version (at the end)
Kevin Power (Apr 15 2020 at 13:21):
You didn't include a slice, does that matter?
Patrick Werner (Apr 15 2020 at 13:23):
hmm good question. Grahame tells me that i'm wrong in this second. brb :-/
Patrick Werner (Apr 15 2020 at 13:35):
ok
"discriminator": [ { "type": "type", "path": "$this.resolve()" } ], "rules": "open" }
Patrick Werner (Apr 15 2020 at 13:35):
you have to resolve of course to compare the type.
Patrick Werner (Apr 15 2020 at 13:36):
I just looked at Haplotype: We are currently pattern slicing on: resolve(code)
Patrick Werner (Apr 15 2020 at 13:36):
BUT: don't habe a pattern on our slices.
Patrick Werner (Apr 15 2020 at 13:36):
i think this is broken/wrong
Kevin Power (Apr 15 2020 at 13:37):
Yea, I think @ Bob Milius wanted us to change our 'haplotype' profile
Kevin Power (Apr 15 2020 at 13:37):
Hence, his request for a 'technical corrections' on STU1 :slight_smile:
Patrick Werner (Apr 15 2020 at 13:38):
i have some other urgent stuff to do atm. Will have a look later, starting with fixing the haplotype profile
Bob Milius (Apr 15 2020 at 14:10):
Just to be clear, if I can't have a derivedFrom to a profile of MolecularSequence inside a profile of Genotype or Haplotype, my HLA Reporting IG will be informed by the CG IG, instead of profiling directly from it. I would prefer to profile it, but I can profile Observation directly if I need to.
In the meantime, I'll play with Patrick's example.
Patrick Werner (Apr 15 2020 at 15:04):
@ Bob Milius it is possible!!! Just the tooling has bugs, and my knowledge is limited.
Patrick Werner (Apr 15 2020 at 15:05):
and we have an issue with the haplotype discriminator/slicing (wondering that this at least worked somehow, to me it looks broken)
Patrick Werner (Apr 15 2020 at 15:07):
- will fix our current sliceDefs in haplotype in the ci build
- get your example flying
Bob Milius (Apr 15 2020 at 15:33):
@Patrick Werner your knowledge is not as limited as mine :upside_down:
Patrick Werner (Apr 16 2020 at 12:17):
just issued/started discussion on 3 bugs in the java validator and IG creator:
https://chat.fhir.org/#narrow/stream/179177-conformance/topic/structuredefinition-normative-version.20errors
https://chat.fhir.org/#narrow/stream/179177-conformance/topic/error.20on.3A.20http.3A.2F.2Fhl7.2Eorg.2Ffhirpath.2FSystem.2EString
https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/packaged.20profiles.20not.20handled.20by.20jekyll
Last updated: Apr 12 2022 at 19:14 UTC
