Stream: implementers
Topic: R3 Candidate build
Grahame Grieve (Feb 21 2017 at 10:44):
If you maintain a reference implementation or other code built from off the FHIR definitions, then the next 5 days is the best time for you to do QA of the candidate build - the only reason for substantiative changes from the current build to the full R3 (other than stated version) is qa feedback from code generators.
@James Agnew @Ewout Kramer @nicola (RIO) @Rick Freeman @Pascal Pfiffner @Brian Postlethwaite
Note that the last change I will make when publishing R3 is the stated version: R3 will be 2.0.0
Grahame Grieve (Feb 21 2017 at 10:44):
that list of names is those that i think/can remember have generated code at one time or another
Josh Mandel (Feb 21 2017 at 12:41):
Adding @Dan Gottlieb (maintains FRED, the resource editor)
Chris Moesel (Feb 21 2017 at 13:28):
@Grahame Grieve Would this have any effect on your terminology server? I'm trying to build an IG using the Jan 2017 ballot version of FHIR (and the igpublisher.jar from it) -- and its connection with the terminology server seems to be broken since last night...
Chris Moesel (Feb 21 2017 at 13:43):
Nevermind. Seems to be working again. I bet I was trying to use it last night when you had the server down to upgrade it (around 1:30-2:30am EST).
Grahame Grieve (Feb 21 2017 at 21:26):
Y. But some data elements have been reordered in XML as of last night
nicola (RIO/SS) (Feb 21 2017 at 21:51):
Thank you, we will try new release
Mustafa Yuksel (Feb 22 2017 at 11:17):
We are not generating code from the definitions, but automatically configuring our server by parsing a capability statement and the FHIR definitions. Although not specific to the R3 candidate build, I have a comment regarding xpath expressions of composite search parameters. I could not find any similar discussion in zulip or forge.
We are dynamically generating search parameters and relevant db indices by parsing the search parameter definitions, specifically the xpaths. The problem is, xpaths of composite search parameters include always all the paths for all possible types, although the verbal description and FHIRpath expression are limited to the relevant types in scope. It would be easier for me to explain with an example: Consider the onset search parameters of Condition; i.e. onset-age, onset-date, onset-info:
"code": "onset-age", "type": "quantity", "description": "Onsets as age or age range", "expression": "Condition.onset.as(Quantity) | Condition.onset.as(Range)", "xpath": "f:Condition/f:onsetDateTime | f:Condition/f:onsetAge | f:Condition/f:onsetPeriod | f:Condition/f:onsetRange | f:Condition/f:onsetString", "code": "onset-date", "type": "date", "description": "Date related onsets (dateTime and Period)", "expression": "Condition.onset.as(dateTime) | Condition.onset.as(Period)", "xpath": "f:Condition/f:onsetDateTime | f:Condition/f:onsetAge | f:Condition/f:onsetPeriod | f:Condition/f:onsetRange | f:Condition/f:onsetString", "code": "onset-info", "type": "string", "description": "Onsets as a string", "expression": "Condition.onset.as(string)", "xpath": "f:Condition/f:onsetDateTime | f:Condition/f:onsetAge | f:Condition/f:onsetPeriod | f:Condition/f:onsetRange | f:Condition/f:onsetString",
I would really appreciate if xpaths are also appropriately restricted to the relevant type(s), just like FHIRpath expressions. We observe the same issue in DSTU2 as well, and there FHIRpath cannot help either.
Pascal Pfiffner (Feb 23 2017 at 14:41):
Thanks for the heads-up Grahame! Does generate well on my end. Is your server up-to-date? It does not return a valid capability statement (missing "kind" and missing "interaction" in "rest[78]"). Also, meta is missing when requesting a summary (I realize marking it _SUBSETTED_ is a _should_ and not a must).
Pascal Pfiffner (Feb 23 2017 at 14:55):
It seems however we are in violation of #5582 in quite some resources by making elements a minOccurs of 1 but not part of a summary. I'm assuming this is known and tolerated?
Grahame Grieve (Feb 24 2017 at 19:12):
I thought we had a hard rule in the tool that elements with minOccurs = 1 had to be in the summary. what's an example?
Grahame Grieve (Feb 24 2017 at 19:13):
@Mustafa Yuksel I will add this to my list; but I don't know whether I will get to it for R3. Unless you want to provide correct XPath statements... that would help
Mustafa Yuksel (Feb 27 2017 at 07:21):
@Grahame Grieve I cannot promise either due current work load, but I will try. I guess the easiest would be to generate from the FHIRpaths. When would be the hard deadline to make this part of R3?
Grahame Grieve (Feb 27 2017 at 08:58):
next 2 weeks
Grahame Grieve (Feb 27 2017 at 08:59):
at the moment, xpath statements are hand-written.
Pascal Pfiffner (Feb 27 2017 at 09:00):
First example is Account.guarantor.party: http://build.fhir.org/account.html
Pascal Pfiffner (Feb 27 2017 at 09:00):
Maybe the rule only applies to top-level properties?
Grahame Grieve (Feb 27 2017 at 09:02):
of course. If guarantor is not in the summary, then none of it's children will be either
Pascal Pfiffner (Feb 27 2017 at 09:03):
But if it is, and a summary is requested, then "party" will not be there. This is expected?
Pascal Pfiffner (Feb 27 2017 at 09:03):
(I mean "if it is present")
Grahame Grieve (Feb 27 2017 at 09:03):
since guarantor is not in the summary, it's irrelevant whether party is labelled to be in the summary or not
Pascal Pfiffner (Feb 27 2017 at 09:04):
Ah, of course. But I keep hitting this situation in capability statement, let me check...
Pascal Pfiffner (Feb 27 2017 at 09:06):
CapabilityStatement.rest.resource.interaction
CapabilityStatement.rest.resource is part of the summary, and CapabilityStatement.rest.resource.interaction has minOccurs=1 but is not part of the summary.
Pascal Pfiffner (Feb 27 2017 at 09:11):
Same with CapabilityStatement.rest.operation.name.
Pascal Pfiffner (Feb 27 2017 at 09:13):
And CapabilityStatement.messaging.event.(mode|focus) and CapabilityStatement.document.code.
Brian Postlethwaite (Feb 28 2017 at 00:51):
The build of the .net client is now working, so I'm running it through its paces on your server today @Grahame Grieve Will let you know if I find anything new.
Grahame Grieve (Feb 28 2017 at 00:53):
ok thanks
Ewout Kramer (Feb 28 2017 at 09:00):
Wow.....Claim.payee.resourceType is a trouble maker. Why would we allow an element with the same name as a "magic" property in json?
Ewout Kramer (Feb 28 2017 at 09:01):
Sure I can add something smart to the parser, but everyone building a parser has to account for this. Feels like changing the name is easier. In the mean time I'll look at what I can do in the .NET json parser...
Pascal Pfiffner (Feb 28 2017 at 09:36):
Wow, hadn't noticed Claim.payee.resourceType. No trouble with our parser and models but that is confusing.
Pascal Pfiffner (Feb 28 2017 at 09:36):
What are thoughts on the minOccurs/isSummary issue in things like CapabilityStatement.rest.resource.interaction?
Paul Knapp (Feb 28 2017 at 09:40):
We certainly could use a different name which is non colliding for X.payee.resourceType. We could change it to X.payee.resource
Ewout Kramer (Feb 28 2017 at 10:10):
Another issue, I get a compile error in our snapshot generator because ElementDefinition.min is now unsignedInt, but ElementDefinition.base.min is still integer. I am pretty sure we want these to align. See GF#12918
Ewout Kramer (Feb 28 2017 at 10:21):
Paul, that would be really helpful
Grahame Grieve (Feb 28 2017 at 10:48):
you can propose a task to change it and make it illegal, but for now, you have to fix the parser
Grahame Grieve (Feb 28 2017 at 10:51):
@Paul Knapp if you want to change the name, FMG has to approve it now.
@Pascal Pfiffner the capability statement stuff I need to fix as part of QA
@Ewout Kramer should we see if we can change the type of ElementDefinition.base.min type immediately?
Paul Knapp (Feb 28 2017 at 10:53):
So 2 tasks: 1) Change payee.resourceType to payee.resource in Claim and EOB, 2) Propose that magic element names NOT be allowed for element name at any level of the resource (and maybe tooling will check and error when time permits.)
Pascal Pfiffner (Feb 28 2017 at 10:54):
I have a list of 215 minOccurs/isSummary discrepancies, will see which are of the Account.guarantor.party non-issue type and which are conflicting.
Paul Knapp (Feb 28 2017 at 10:54):
I can raise with FMG tomorrow, also while discussion with Brian P saw that the binding strength is not aligned, so could ask to fix that too.
Grahame Grieve (Feb 28 2017 at 10:55):
there's obviously something wrong with my algorithm - it's supposed to disallow that
Paul Knapp (Feb 28 2017 at 10:57):
as in your tooling was already supposed to catch magic/reserved element names? or are you talking to Pascal?
Grahame Grieve (Feb 28 2017 at 11:04):
talking to Pascal. my tooling does catch other reserved words, just not that one (well, that one has not been reserved, because no one ever used it before)
Ewout Kramer (Feb 28 2017 at 11:55):
@Grahame Grieve - yes, I'd prefer to, otherwise I'd just be hacking work-arounds that I will have to remove later on....
Pascal Pfiffner (Feb 28 2017 at 15:29):
@Grahame Grieve here's a list of elements with n_min > 0 whose parent element isSummary = true but the element itself is not part of the summary.
CapabilityStatement.rest.resource.interaction CapabilityStatement.rest.operation.name CapabilityStatement.messaging.event.mode CapabilityStatement.messaging.event.focus CapabilityStatement.document.mode Consent.actor.role Consent.actor.reference Consent.except.actor.role Consent.except.actor.reference Encounter.diagnosis.condition Observation.related.target Questionnaire.item.enableWhen.question
I am not sure about questionnaire. Questionnaire.item is not part of the summary but Questionnaire.item.enableWhen is. Not sure how that is expected to behave.
Pascal Pfiffner (Feb 28 2017 at 15:39):
Not sure this is also a tooling issue: these 3 value sets are part of a required binding it at least one resource but are missing from valuesets.json:
http://hl7.org/fhir/ValueSet/v3-ActIncidentCode http://hl7.org/fhir/ValueSet/v3-ActInvoiceGroupCode http://hl7.org/fhir/ValueSet/v3-ConfidentialityClassification
Ewout Kramer (Feb 28 2017 at 16:51):
I found that certain extensions in the build, like the file 'extension-us-core-race.xml' still uses an older format of StructureDefinition: in this file the discriminator is still a single primitive string....
Eric Haas (Feb 28 2017 at 16:54):
mmm. extension-us-core-race.xml should be out of the build. It was moved to US Core
Eric Haas (Feb 28 2017 at 17:03):
I didn't remove it completely - didn't realize that it was still generating the sd files
Eric Haas (Feb 28 2017 at 17:10):
and the us patient example is still there too - in the publish file?
Eric Haas (Feb 28 2017 at 17:28):
does that mean deprecated structures and examples (marked with !) in the source spreadsheets are being validated by toolsmiths?
Lloyd McKenzie (Feb 28 2017 at 18:21):
us state code should move out of core too?
Eric Haas (Feb 28 2017 at 18:50):
There is lot of content in the build that is US specific but waiting for the registries.....
Lloyd McKenzie (Feb 28 2017 at 18:57):
Why would registries affect whether it's published in US Core vs. FHIR Core?
Eric Haas (Feb 28 2017 at 19:02):
well us state codes are not needed in US-Core right now since we don'd constrain address so this would be informational only. Better to have a searchable registry for US codesystems, valuesets, Identifier systems than to stick US-Core. Don't you think?
Grahame Grieve (Mar 01 2017 at 02:11):
why are we stil generating the sd files? In fact, given that their format is wrong, I don't think we are still generating them. if you found them in your local copy, you need to clearn that out occasionally
Ewout Kramer (Mar 01 2017 at 08:45):
Well, I copy *all* files with the name extension-*.xml that are in the publish directory into our unit-tests. Maybe I should not do that then ;-)
Paul Knapp (Mar 01 2017 at 09:28):
US state codes aren't just used by the US Realm.
Ewout Kramer (Mar 01 2017 at 14:50):
@Eric Haas @Grahame Grieve Ah, yes, cleaning out the build worked.
Ewout Kramer (Mar 01 2017 at 14:51):
Grahame, what's in ElementDefinition.constraint.source? Sometimes it seems to be the name of the resource/datatype where the constraint originated, sometimes it's an *id* of an element (or it looks like that):
<source value="Observation:vitalsignsprofile"/>
Ewout Kramer (Mar 01 2017 at 14:52):
Found this in <url value="http://hl7.org/fhir/StructureDefinition/bodyweight"/>
Ewout Kramer (Mar 01 2017 at 15:17):
I have done a comparison of snapshots generated by the .NET and the Java stack. The good news: I don't think we've ever been this close. The bad news: there are still differences, and some of them remind me of late thursday night discussions during WGMs.
Ewout Kramer (Mar 01 2017 at 15:17):
To find out more, I have detailed the differences here: https://gist.github.com/ewoutkramer/f10e36a51747759f7cca5d54e9cd44e6
Ewout Kramer (Mar 01 2017 at 15:18):
@Michel Rutten @Grahame Grieve @Chris Grenz I hope you find this comparison useful.
Chris Grenz (Mar 01 2017 at 16:01):
@Ewout Kramer Excellent - I agree with your conclusions. The inclusion of base constraint is probably the only remaining point of contention. It's interesting that your example here includes the Observation:vitalsignsprofile id - this is an example of a root element having a sliceName that shouldn't (I think) be allowed. We need a constriant that disallows sliceName without slicing. GF#12849 addresses this and is deferred...this is and will be an issue for DSTU3 publication that will be very confusing for US-Core (and other) implementers
Ewout Kramer (Mar 01 2017 at 16:03):
I agree, that's the only point of contention left....which means we're in a pretty good position ;-)
Ewout Kramer (Mar 01 2017 at 16:06):
Note that in Grahame's id generation, the id is considered to be opaque ;-) So this is probably not meant to indicate a slicename (there is no explicit <sliceName> element here), i think Grahame uses a lower-cased profile id (from the StructureDefinition.url) to generate unique ids here....
Chris Grenz (Mar 01 2017 at 16:06):
I see that GF#12259 "missed the boat" - concerned that this leaves the behavior unclear for type slices
Ewout Kramer (Mar 01 2017 at 16:06):
Chris Grenz (Mar 01 2017 at 16:07):
The id is opaque? I thought it was required to be of the agreed upon format?
Ewout Kramer (Mar 01 2017 at 16:07):
Yes, that's too bad - then again there's only so much even GG can do before a deadline.....
Chris Grenz (Mar 01 2017 at 16:08):
Totally understand...would like to at least give some kind of guidance....
Chris Grenz (Mar 01 2017 at 16:09):
Mustn't the id be TypeName.element:sliceName/resliceName.element...etc?
Ewout Kramer (Mar 01 2017 at 16:09):
Hehehe, I already said that many of the differences I found remind me of late-thurday-night discussions ;-)
Ewout Kramer (Mar 01 2017 at 16:09):
I do remember this was considered a useful format, but not something you can depend on.....
Ewout Kramer (Mar 01 2017 at 16:10):
Maybe we should open up another topic about "R3 Candidate build - SD differences" to not pollute this thread too much here.
Grahame Grieve (Mar 01 2017 at 19:16):
the root element id of a profile must have something in the name, so that the id does not clash with the id of the element it is a profile of
Mustafa Yuksel (Mar 05 2017 at 20:53):
I finally found some time this weekend to work on xpath statement correction. I worked on the latest build, with lastUpdated time of "2017-03-04T01:00:52.026+00:00". I filtered with a simple xslt all the SearchParameters that have ORed xpath statements, which turned out to be 73 in total. Then I manually checked all; only a small portion (8 out of 73) have problems.
Below, I present those SearchParameters with the current fhirpaths, xpaths and with my updates. New xpaths are available in the xpathNew element. I updated 2 fhirpath statements as well, due to age vs. quantity inconsistencies. These are available in the expressionNew element.
<SearchParameter> <url value="http://hl7.org/fhir/SearchParameter/ClinicalImpression-finding-code"/> <type value="token"/> <expression value="ClinicalImpression.finding.item.as(CodeableConcept)"/> <xpath value="f:ClinicalImpression/f:finding/f:itemCodeableConcept | f:ClinicalImpression/f:finding/f:itemReference"/> <xpathNew value="f:ClinicalImpression/f:finding/f:itemCodeableConcept"/> </SearchParameter> <SearchParameter> <url value="http://hl7.org/fhir/SearchParameter/ClinicalImpression-finding-ref"/> <type value="reference"/> <expression value="ClinicalImpression.finding.item.as(Reference)"/> <xpath value="f:ClinicalImpression/f:finding/f:itemCodeableConcept | f:ClinicalImpression/f:finding/f:itemReference"/> <xpathNew value="f:ClinicalImpression/f:finding/f:itemReference"/> </SearchParameter> <SearchParameter> <url value="http://hl7.org/fhir/SearchParameter/Condition-abatement-age"/> <type value="quantity"/> <expression value="Condition.abatement.as(Quantity) | Condition.abatement.as(Range) | Condition.abatement.as(Age)"/> <xpath value="f:Condition/f:abatementDateTime | f:Condition/f:abatementAge | f:Condition/f:abatementBoolean | f:Condition/f:abatementPeriod | f:Condition/f:abatementRange | f:Condition/f:abatementString"/> <expressionNew value="Condition.abatement.as(Range) | Condition.abatement.as(Age)"/> <xpathNew value="f:Condition/f:abatementAge | f:Condition/f:abatementRange"/> </SearchParameter> <SearchParameter> <url value="http://hl7.org/fhir/SearchParameter/Condition-abatement-date"/> <type value="date"/> <expression value="Condition.abatement.as(dateTime) | Condition.abatement.as(Period)"/> <xpath value="f:Condition/f:abatementDateTime | f:Condition/f:abatementAge | f:Condition/f:abatementBoolean | f:Condition/f:abatementPeriod | f:Condition/f:abatementRange | f:Condition/f:abatementString"/> <xpathNew value="f:Condition/f:abatementDateTime | f:Condition/f:abatementPeriod"/> </SearchParameter> <SearchParameter> <url value="http://hl7.org/fhir/SearchParameter/Condition-abatement-string"/> <type value="string"/> <expression value="Condition.abatement.as(string)"/> <xpath value="f:Condition/f:abatementDateTime | f:Condition/f:abatementAge | f:Condition/f:abatementBoolean | f:Condition/f:abatementPeriod | f:Condition/f:abatementRange | f:Condition/f:abatementString"/> <xpathNew value="f:Condition/f:abatementString"/> </SearchParameter> <SearchParameter> <url value="http://hl7.org/fhir/SearchParameter/Condition-onset-age"/> <type value="quantity"/> <expression value="Condition.onset.as(Quantity) | Condition.onset.as(Range)"/> <xpath value="f:Condition/f:onsetDateTime | f:Condition/f:onsetAge | f:Condition/f:onsetPeriod | f:Condition/f:onsetRange | f:Condition/f:onsetString"/> <expressionNew value="Condition.onset.as(Age) | Condition.onset.as(Range)"/> <xpathNew value="f:Condition/f:onsetAge | f:Condition/f:onsetRange"/> </SearchParameter> <SearchParameter> <url value="http://hl7.org/fhir/SearchParameter/Condition-onset-date"/> <type value="date"/> <expression value="Condition.onset.as(dateTime) | Condition.onset.as(Period)"/> <xpath value="f:Condition/f:onsetDateTime | f:Condition/f:onsetAge | f:Condition/f:onsetPeriod | f:Condition/f:onsetRange | f:Condition/f:onsetString"/> <xpathNew value="f:Condition/f:onsetDateTime | f:Condition/f:onsetPeriod"/> </SearchParameter> <SearchParameter> <url value="http://hl7.org/fhir/SearchParameter/Condition-onset-info"/> <type value="string"/> <expression value="Condition.onset.as(string)"/> <xpath value="f:Condition/f:onsetDateTime | f:Condition/f:onsetAge | f:Condition/f:onsetPeriod | f:Condition/f:onsetRange | f:Condition/f:onsetString"/> <xpathNew value="f:Condition/f:onsetString"/> </SearchParameter>
Mustafa Yuksel (Mar 05 2017 at 21:07):
In addition, I noticed that the last 2 SearchParameters, which are I guess the only ones in the whole set defined on an extension, contain the same xpath statement twice (i.e. duplicate entry), and they also do not have a fhirpath expression:
<SearchParameter> <url value="http://hl7.org/fhir/SearchParameter/elementdefinition-11179-DataElement-objectClass"/> <type value="token"/> <xpath value="f:DataElement/f:element/f:mapping/f:extension[@url='http://hl7.org/fhir/StructureDefinition/11179-objectClass'] | f:DataElement/f:element/f:mapping/f:extension[@url='http://hl7.org/fhir/StructureDefinition/11179-objectClass']"/> </SearchParameter> <SearchParameter> <url value="http://hl7.org/fhir/SearchParameter/elementdefinition-11179-DataElement-objectClassProperty"/> <type value="token"/> <xpath value="f:DataElement/f:element/f:mapping/f:extension[@url='http://hl7.org/fhir/StructureDefinition/11179-objectClassProperty'] | f:DataElement/f:element/f:mapping/f:extension[@url='http://hl7.org/fhir/StructureDefinition/11179-objectClassProperty']"/> </SearchParameter>
Grahame Grieve (Mar 05 2017 at 22:39):
ok thanks. I'll work through these soon
Grahame Grieve (Mar 06 2017 at 06:50):
fixed
Mustafa Yuksel (Mar 06 2017 at 15:10):
Ewout Kramer (Mar 09 2017 at 14:53):
I found this in some DSTU2 invariants in profiles-others:
extension(%ext-11179-permitted-value-valueset).count()
These are incorrect, since accoding to the FhirPath spec, the external variable reference should be an id, and cannot contain "-", hence this should be written as
extension(%"ext-11179-permitted-andso-on")
I don't know whether these definitions have moved somewhere else (in STU3 they are no longer in profiles-others), but this could be a common mistake still found in STU3.
Grahame Grieve (Mar 09 2017 at 19:14):
not a possible error in STU3
Last updated: Apr 12 2022 at 19:14 UTC
