Stream: conformance
Topic: Test Cases for Snapshot Generation
Grahame Grieve (Mar 23 2017 at 22:35):
Somehow, at least one signficant error was not picked up in the QA process for release 3. We're going to have to do a technical correction for it.
Grahame Grieve (Mar 23 2017 at 22:35):
I'm working on a set of test cases for snapshot generation. Right now, they have the following form:
Grahame Grieve (Mar 23 2017 at 22:36):
- a test script, with a series of operations
- each operation is $snapshot, with a differential provided, referring directly to to a base definition or to one o the other profiles in the test script
- for each operation, there's a series of fhirpath statements that must be true about the snapshot
Grahame Grieve (Mar 23 2017 at 22:37):
@Ewout Kramer is this something that you would support in the C# context? @hat about @Chris Grenz ?
Chris Grenz (Mar 26 2017 at 22:51):
Unfortunately I don't have a fluentpath parser working...what's the error?
Grahame Grieve (Mar 27 2017 at 01:39):
not sure how to describe it yet
Grahame Grieve (Mar 27 2017 at 21:18):
So an arcane and deeply technical arising out of these tests.
Grahame Grieve (Mar 27 2017 at 21:19):
Should you be able to walk into a type in a differential without explicitly doing so
Grahame Grieve (Mar 27 2017 at 21:19):
to illustrate, you might decide to profile Patient, and walk into the identifier:
Grahame Grieve (Mar 27 2017 at 21:19):
so you have a differential like this:
Patient
Patient.identifier
Patient.identifier.system fixed = [some URL]
Grahame Grieve (Mar 27 2017 at 21:20):
but should you be allowed to have a differential like this:
Grahame Grieve (Mar 27 2017 at 21:20):
Patient.identiifer.system fixed = [some URL]
Grahame Grieve (Mar 27 2017 at 21:20):
e.g. just jump straight into the deep path
Lloyd McKenzie (Mar 27 2017 at 22:37):
My answer is "sure" - unless there's a reason why from a tooling perspective that's problematic.
Lloyd McKenzie (Mar 27 2017 at 22:38):
What additional information does having a "bare" element in the differential with the path "Patient.identifier" provide to the tooling - or anything else?
Lloyd McKenzie (Mar 27 2017 at 22:38):
Perhaps it makes rendering easier?
Grahame Grieve (Mar 27 2017 at 22:41):
it's related to the sequence of thought in the snapshot generation - you're walking the sequence in the base, looking for profiling in the differential
Grahame Grieve (Mar 27 2017 at 22:41):
then, having found something, you look at whether you walk into that
Lloyd McKenzie (Mar 27 2017 at 23:04):
I have no objection to requiring it. As you recently pointed out to me, we have to do it if there's a sliceName on the parent. Requiring regardless of whether there's a sliceName would make things consistent.
Grahame Grieve (Mar 28 2017 at 00:32):
figured out to do it in the tools
Ewout Kramer (Mar 28 2017 at 10:52):
Sure, though I'd love to have the .NET/Java snapshot generators closely aligned (we discussed the current differences), so I can run a compare over all differentials/snapshots in the build. Sure this won't hit every code path but would catch things we don't think about creating fhirpath statements!
Michel Rutten (Mar 29 2017 at 09:17):
"Should you be able to walk into a type in a differential without explicitly doing so"
The .NET snapshot generator first completes the differential by adding missing parent elements before further processing. As Lloyd mentions, parent elements with a slice name must always be included. But the diff does not strictly need to include unnamed parent elements.
Chris Grenz (Mar 29 2017 at 19:04):
IMO, there should be no requirement in a differential to include anything you're not changing. Sounds like that's where this thread already is though, so, um.. ditto? ;)
Lloyd McKenzie (Mar 29 2017 at 19:32):
Differentials do need to include elements with slice names to provide context for child elements - because we can't rely on ids for navigation. So it's not true that the *only* time elements appear in differential is when you're chainging something
Chris Grenz (Mar 29 2017 at 19:33):
We can't rely on ids for navigation? Why not...that was the whole point!
Chris Grenz (Mar 29 2017 at 19:35):
http://hl7.org/fhir/elementdefinition.html#id makes me think we can
Chris Grenz (Mar 29 2017 at 19:36):
I agree though that a *new* slice can't be introduced only via the id since the sliceName element must be set at the slice root.
Chris Grenz (Mar 29 2017 at 19:39):
But I define a slice in Profile A and then create Profile B based on Profile A, I needn't restate the slice root to modify a sub-element of the slice:
Profile A differential:
Patient.identifier (slicing)
Patient.identifier:mrn (sliceName)
Profile B differential:
Patient.identifier:mrn.type.coding.code (constraint)
Lloyd McKenzie (Mar 29 2017 at 19:46):
I didn't think we had mandated that. Will let @Grahame Grieve respond because he'd been the one who was reluctant
Chris Grenz (Mar 29 2017 at 19:47):
There's SHALLs on existence and format. I think it's done (although I'm always happy to hear Grahame out!).
Grahame Grieve (Mar 29 2017 at 19:52):
actually, what we didn't mandate is that an ElementDefinition has an id. I'm populating the Ids whenever I see them, but we have not said that differentials SHALL contain ids. And when they don't, you can't infer them correctly unless the slice is defined
Chris Grenz (Mar 29 2017 at 19:53):
"In addition to the path, every ElementDefinition SHALL have a populated id,"
Grahame Grieve (Mar 29 2017 at 19:53):
oh. so we did?
Chris Grenz (Mar 29 2017 at 19:53):
yep
Grahame Grieve (Mar 29 2017 at 19:53):
@Michel Rutten is forge populating the ids for R3?
Michel Rutten (Mar 30 2017 at 08:17):
The Snapshot generator in the .NET API for STU3 will generated element id's according to the proposed format. Forge for STU3 will also support this. However I doubt that it's safe to assume that input profiles will always have element id's in the canonical format. So I'm aiming for our implementations to gracefully handle missing element id's.
Lloyd McKenzie (Mar 30 2017 at 18:17):
Certainly within HL7 when authoring by hand or with spreadsheets, we don't populate ids in the differential. Those ids all get assigned as part of the snapshot generation process
Chris Grenz (Mar 30 2017 at 19:05):
Some of my tooling makes up for missing ids, but in STU3, missing ids in snapshot or differential is non-conformant and should be treated as such.
Lloyd McKenzie (Mar 30 2017 at 19:08):
Given that they can be generated - and are easy enough to mess up, I really don't want them mandated in the differential if no snapshot is present. Creating profiles by hand is enough of a pain as it is. (And until the tools are robust enough to handle all the edge cases, we need to support hand-edited profiles.)
Chris Grenz (Mar 30 2017 at 19:24):
I'd argue that mandating ids relieves the complexity of relying on ordering in tooling and actually makes the profiles easier to hand-edit. IMHO...
Last updated: Apr 12 2022 at 19:14 UTC
