FHIR Chat · Slicing and value sets

Stream: conformance

Topic: Slicing and value sets

Grahame Grieve (Aug 04 2019 at 23:41):

I'm looking at why a nictiz profile doesn't validate (@Alexander Henket )

Grahame Grieve (Aug 04 2019 at 23:41):

https://simplifier.net/NictizSTU3-Zib2017/ZIB-Product/~overview

Grahame Grieve (Aug 04 2019 at 23:41):

what it does is slice a Coding:

Grahame Grieve (Aug 04 2019 at 23:41):

        <element id="Medication.code.coding">
            <path value="Medication.code.coding" />
            <slicing>
                <discriminator>
                    <type value="value" />
                    <path value="system" />
                </discriminator>
                <rules value="open" />
            </slicing>
            <short value="MedicationCode" />
            <definition value="Coding medication in the Netherlands is done on the basis of the G standard (issued by Z-index), which is filled under the direction of KNMP.

The coded medication can be expressed as:

 - GTIN International Article Number
 - KNMP article number = ATKODE (2.16.840.1.113883.2.4.4.8)
 - Trade product code (HPK)
 - Prescription code (PRK)
 - Generic product code (GPK)
 - Anatomic Therapeutic Classification code (ATC)
 - SNOMED CT code
 - Substance Name Code (SNK)
 - Substance Name Code, in combination with Route of Administration (SSK)
 - 90.000.000 number (individual code setting) (or similar from the facility)

The GTIN enables identification of the product including its origin with a barcode.
The ATKODE is the number with which wholesalers link the article to pharmacy systems (e.g. a box with 3 strips of 10 tablets).
The HPK is the code for the trade product (with the brand name) as used per dose/per time the medication is taken (1 pill, 1 puff, 1ml)
The PRK codes for the same product as the HPK does, but is not linked to a manufacturer (no brand name, no characteristics such as color, geometrical shape etc.). This code will enable a generic prescription, while still defining which trade product can be taken (e.g. a 200ml bag).
The generic product code defines the composition of a product, and is sufficient for recording the prescription, but not the order.
The prescription code (PRK) was developed and added to the older generic (GPK) and supplier-specific (HPK, ATKODE) coding to enable a generic product to be entered without listing a specific brand on the one hand, and to enable providing enough information to support the pharmacy supplying it on the other.

The Substance Name Code (SNK) and the Substance Name Code, in combination with Route of Administration (SSK) are used to prescribe at a more generic level.

The GTIN coding is used for the implementation of a barcode scanning standard and to be able to trace the origin of the product.

The 90.000.000 number is used in accordance with national agreements." />

Grahame Grieve (Aug 04 2019 at 23:42):

ok that seems straight forward - the slices are differentiated by system.

Grahame Grieve (Aug 04 2019 at 23:42):

then, the slice is defined like this:

Grahame Grieve (Aug 04 2019 at 23:42):

        <element id="Medication.code.coding:productCodeZICodelijst">
            <path value="Medication.code.coding" />
            <sliceName value="productCodeZICodelijst" />
            <max value="1" />
            <binding>
                <strength value="required" />
                <description value="ProductCodeZICodelijst" />
                <valueSetReference>
                    <reference value="http://decor.nictiz.nl/fhir/ValueSet/2.16.840.1.113883.2.4.3.11.60.40.2.9.7.1--20171231000000" />
                    <display value="ProductCodeZICodelijst" />
                </valueSetReference>
            </binding>
        </element>

Grahame Grieve (Aug 04 2019 at 23:44):

this doesn't work in the validator because the definition of the slicing says the the discriminator is system, but then it doesn't define a fixed value for the system; instead, this is implied by the value set defined in the coding itself ($this). So the validator says - quite rightly,in my view:

Grahame Grieve (Aug 04 2019 at 23:44):

ERROR: Medication.code.coding[0]: Could not match discriminator ([system]) for slice Medication.code.coding:productCodeZICodelijst in profile http://nictiz.nl/fhir/StructureDefinition/zib-Product - does not have fixed value, binding or existence assertions

Grahame Grieve (Aug 04 2019 at 23:45):

does anyone disagree with my analysis?

Richard Townley-O'Neill (Aug 04 2019 at 23:57):

I think that it is too obscure to fix the value of system by binding to a value set (when value sets can use multiple code systems).
The message has a problems as it says that the element doesn't have a binding assertion, but it does.

Grahame Grieve (Aug 04 2019 at 23:59):

the element does not have a binding assertion

Grahame Grieve (Aug 04 2019 at 23:59):

because it is looking for something on a system element

Richard Townley-O'Neill (Aug 05 2019 at 00:01):

...and the binding is on the coding.

Grahame Grieve (Aug 05 2019 at 00:01):

yes

Richard Townley-O'Neill (Aug 05 2019 at 00:04):

maybe change the wording to

profile http://nictiz.nl/fhir/StructureDefinition/zib-Product - discriminator does not have fixed value, binding or existence assertions

Grahame Grieve (Aug 05 2019 at 00:06):

Alexander Henket (Aug 05 2019 at 00:17):

Does slicing by Value Set work in all tools yet? We sliced on system for lack in tooling support in 2015/2016 when we started creating them

Alexander Henket (Aug 05 2019 at 00:17):

@Ardon Toonstra can you follow this thread while I’m on holiday?

Grahame Grieve (Aug 05 2019 at 00:17):

Don't know. I'll change it and test

Alexander Henket (Aug 05 2019 at 00:23):

By the way the STU3 validation under Touchstone apparently works with this construct. Or at least this is the first complaint I’ve heard so far. @Richard Ettema does slicing by Value Set work under Touchstone. Wouldn’t want to change the profiles for one tool and break it for another

Grahame Grieve (Aug 05 2019 at 00:27):

Touchstone uses the same validator code. So it probably didn't really work - just wasn't even tested in the past

Rob Hausam (Aug 05 2019 at 00:27):

I think you could try pattern slicing on the coding ($this) and discriminate based on the value set expansions (not actually directly on the bindings) - that's assuming that the value set expansions don't overlap (which is probably the case here?). I'm also interested in verifying that this actually works (and not just that it doesn't give errors).

Grahame Grieve (Aug 05 2019 at 00:27):

I have to sort out a heap of terminology stuff to test this one

Grahame Grieve (Aug 05 2019 at 00:27):

I might simplify it a little

Lloyd McKenzie (Aug 05 2019 at 01:14):

If the discriminator is 'system', then 'system' must either have a fixed value or there must be a value set on the 'system' element itself.

Grahame Grieve (Aug 05 2019 at 02:43):

ok, these tests:

Grahame Grieve (Aug 05 2019 at 02:43):

that's what we want to test, yes?

Grahame Grieve (Aug 05 2019 at 05:41):

... and it works...

Ardon Toonstra (Aug 06 2019 at 11:04):

Thanks for checking this out Grahame. I looked at your tests and agree that this is what we want to test. Seems like we should improve our profiles accordingly. So, to confirm, we only have to change our discriminator.path from system to $this, is that correct?

Ardon Toonstra (Aug 06 2019 at 11:05):

@Richard Ettema does WildFHIR / Touchstone support this?

Ardon Toonstra (Aug 06 2019 at 11:06):

I will check out what the .NET validator does

Ardon Toonstra (Aug 06 2019 at 11:58):

@Grahame Grieve , I would expect the below instance to fail in the validator, right?

<Medication xmlns="http://hl7.org/fhir">
  <code>
    <coding>
      <system value="http://tst.org/fhir/CodeSystem/test-meds"/>
      <code value="s1"/>
    </coding>
    <coding>
      <system value="http://tst.org/fhir/CodeSystem/test-meds"/>
      <code value="s1a"/>
    </coding>
    <coding>
      <system value="http://tst.org/fhir/CodeSystem/test-meds"/>
      <code value="s3"/>
    </coding>
    <text value="some text"/>
  </code>
  <status value="active"/>
  <isBrand value="false"/>
</Medication>

Rob Hausam (Aug 06 2019 at 11:59):

This is good. My question is, since the discrimination is based on contents of the value set expansion compared to the instance data and not on a fixed value, should the discriminator type be (1) value (as it is currently in these tests) or (2) pattern (which seems to me like it might be a more logical fit)? Or do we intend to say that in this case you can use either value or pattern and both will work? Presumably we should also test with pattern (if we decide that's a valid option, and probably even if we don't).

Grahame Grieve (Aug 06 2019 at 13:52):

I think that should fail, and it looks just like my failing example in the validator tests

Grahame Grieve (Aug 06 2019 at 13:53):

@Rob Hausam I have tested value. I'm not really sure what pattern means here. value means that the coding is in the value set. I don't know what pattern would mean...

Rob Hausam (Aug 06 2019 at 14:53):

The notes on the discriminator type 'value' here say:

This is the most commonly used discriminator type: to decide based on the value of an element. Elements used like this are mostly primitive types- code, uri.

That's not what we're doing in this case. We're not specifying a particular element in the discriminator path, and the slices don't fix any values - they declare a binding. We're testing the instance data to see if it matches with one of the codes in the expansion of the bound value set. That sounds very much like the idea of matching on a pattern (although with a somewhat different application of it). Maybe what we actually should have is a 'binding' discriminator type (whatever we would want to call it) to make this clearer? But I think that in lieu of that, allowing either 'value' or 'pattern' to be used makes sense, and seems consistent with how we've documented it:

If the type is value, or pattern, then the element definition must use either:

ElementDefinition.fixed[x], or

ElementDefinition.pattern[x], or

if the element has a terminology binding, a required binding with a Value Set that enumerates the list of possible codes in the value set ("extensional definition")

Rob Hausam (Aug 06 2019 at 15:03):

A question on a different aspect of this is, do we really want to restrict discriminating based on a value set binding only to extensionally defined value sets? I agree that the binding needs to be required, but I can't see why we wouldn't want to be able to do it on intensionally defined value sets that are supported by the terminology server (and maybe that's already the case)?

Michel Rutten (Aug 06 2019 at 15:05):

Performance comes to mind. A profile validator would need to reach out to a TX server to evaluate the discriminator. This might not scale...

Rob Hausam (Aug 06 2019 at 15:07):

I agree that may be an issue. But we need to decide (I think) whether we actually disallow or explicitly don't support it.

Rob Hausam (Aug 06 2019 at 15:08):

Or if we've already decided it (as currently documented) and are comfortable sticking with that, we can.

Rob Hausam (Aug 06 2019 at 15:10):

And I didn't want to derail the "value and/or pattern" discriminator type discussion.

Michel Rutten (Aug 06 2019 at 15:39):

Feature-wise, this seems like a natural extension of the current discriminator specification. It may encourage modelers to introduce potential performance bottlenecks without noticing. But the spec could explicitly warn for that.

Grahame Grieve (Aug 06 2019 at 21:01):

I think we didn't see the point of discriminating by an intensionally defined value set. The point of the discriminator is too allow an implementation to quickly determine which slice is which without having to do any validation. Explicitly defined value sets lend themselves to turning into switch statements....

Rob Hausam (Aug 07 2019 at 02:50):

Yes, I think that's a reasonable rationale for making that distinction.

Rob Hausam (Aug 07 2019 at 02:52):

Where are we on the "value and/or pattern" discriminator type for value set slicing discussion?

Grahame Grieve (Aug 07 2019 at 02:55):

value. it's the value of the coding etc that is submitted to test the binding

Rob Hausam (Aug 07 2019 at 03:02):

As I said in the earlier post, our current documentation implies otherwise - both value and pattern can use a terminology binding (as noted in the 3rd bullet). That's what it says. If that's wrong, then we'll have to change it (at least make it much clearer than it is now that value is the only correct choice in this case).

Grahame Grieve (Aug 07 2019 at 06:18):

I don't know what it means to say that a pattern can be used with a binding. I don't know if anyone else has any ideas what we might have meant by that

Martijn Hermans (Aug 07 2019 at 12:20):

Thank you all for helping me with this issue! If I understand correctly: I can just wait untill the profile is adjusted. (it doesn't work now because the only way to see which slice we are dealing with is to look at the valuereference, right?)

Martijn Hermans (Aug 07 2019 at 12:21):

I have one more question about the profile: https://simplifier.net/NictizSTU3-Zib2017/ZIB-MedicationAgreement

Martijn Hermans (Aug 07 2019 at 12:22):

If I validate a resource on basis of this profile I get the following warning:

Martijn Hermans (Aug 07 2019 at 12:23):

NotSupported : Slicing with a discriminator of type 'Type' is not yet supported by this validator.

Does this just mean the validator cannot currently validate this slice. Or does it mean the profile may have a problem?

Rob Hausam (Aug 07 2019 at 12:26):

@Grahame Grieve If you read through the definition of ElementDefinition.pattern[x], I agree that 'pattern' as it is described there does not fit with the slicing on a value set use case that we are discussing here. The documentation for ElementDefinition.binding and its subelements doesn't mention anything about how it works in slicing (and maybe it doesn't need to). The documentation for ElementDefinition.slicing.discriminator.type basically defers to the discriminator-type value set, which, as in the Profiling FHIR page, states that "The slices have different values in the nominated element." If you take that statement at face value, it doesn't include the idea that for use as a 'value' type discriminator, specifying a binding to an extensionally defined value set is equivalent to specifying a fixed value for the nominated element. That's too broad a stretch to be an obvious conclusion to reach without a more explicit statement (or multiple statements). If we want to broaden the declared scope of 'value' to cover this use (and to disallow 'pattern' for it) then we need to enhance the documentation to do that (I have some ideas on that).

Rob Hausam (Aug 07 2019 at 12:46):

@Martijn Hermans My guess is that it probably means what you said first, that the validator cannot currently validate this slice. I don't know that the profile is wrong (rather than just unsupported), but it does seem to me to be incomplete. It has sliced MedicationRequest.dosageInstruction.dose[x], but hasn't defined any slices for it.

Michel Rutten (Aug 07 2019 at 13:21):

@Martijn Hermans although FHIR allows slice-by-profile, in practice this feature is not implemented/supported yet by the popular FHIR frameworks (HAPI/Java & .NET). Also keep in mind that evaluation of such a constraint can be very computationally intensive.

Grahame Grieve (Aug 07 2019 at 13:22):

Java validation can now

Michel Rutten (Aug 07 2019 at 13:30):

Ah, nice work! I think Ewout almost has this in place too.

Ardon Toonstra (Aug 08 2019 at 12:10):

I made an issue for the .NET validator to support slicing based on valueset. I couldn't reproduce the expected validation errors based on the test data provided by Grahame.

Ardon Toonstra (Oct 11 2019 at 13:19):

Hi all!

The .NET validator now supports slicing discriminated by ValueSet. In our profiles, we have occasionally defined slices based on a valueset binding and one or more mandatory slices with fixed values on .system and .code. The .NET validator does not yet handle this combined kind of slicing.

My concern: is this valid FHIR? Should a validator be smart enough to look at valueset binding AND fixed values given in a slice with this discriminator:

        <discriminator>
          <type value="value" />
          <path value="$this" />
        </discriminator>

Lloyd McKenzie (Oct 11 2019 at 14:36):

The problem is that you discriminator is at two different levels. A valueset constrains the values of a Coding. If you're declaring fixed values on the 'code' and 'system', that's not happening at the coding level. I think the correct solution is to treat a value set binding as legal for both 'value' and 'pattern' constraints. Then you could declare a value set on the CodeableConcept or a pattern on the CodeableConcept and the discriminator would work for both. @Grahame Grieve ?

Grahame Grieve (Oct 11 2019 at 16:44):

I'm not sure. I'd have to look at instance before I was sure what Ardon was asking

Lloyd McKenzie (Oct 11 2019 at 16:47):

My question wasn't so much based on what Ardon was asking as wondering whether it's reasonable to allow a valueset assertion to work for 'pattern' slices as well as 'value' slices. In practice, valueset assertion works more like 'pattern' than like 'value' anyhow - it just checks code + system and only cares about a match in one of the codings. It ignores everything else. If I were designing it now, I might actually argue that valueset doesn't make sense for a 'value' match unless you're dealing with code. However, I'm ok with leaving that bit as it is at this point.

Rob Hausam (Oct 11 2019 at 18:39):

There's been conversation about this before. I agree that the fit for valueset assertion actually does seem to be better with pattern, as you describe, so I think it would make sense at least to allow for both.

Alexander Henket (Oct 14 2019 at 08:24):

Hope this helps. This is the instance we want to validate, so we're basically looking for a syntax to do that:

<!-- Full example: https://github.com/Nictiz/Nictiz-STU3-Zib2017/blob/develop/Examples/medmij-bgz-fhir3-0-1-labresult-ts-01.xml -->
<!-- Full profile: https://github.com/Nictiz/Nictiz-STU3-Zib2017/blob/develop/Profiles%20-%20ZIB%202017/zib-LaboratoryTestResult-Observation.xml -->
<Observation xmlns="http://hl7.org/fhir">
    <id value="medmij-bgz-labresult-ts-01"/>
    <meta>
        <profile value="http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-Observation"/>
    </meta>
    <status value="final"/>
    <!-- Fixed values for coding.system and coding.code (Dutch extension of SNOMED hence fails at regular terminology servers) -->
    <category>
        <coding>
            <system value="http://snomed.info/sct"/>
            <code value="49581000146104"/>
            <display value="Laboratory test finding (finding)"/>
        </coding>
    </category>
    <!-- Secondary category based on a binding -->
    <category>
        <coding>
            <system value="http://snomed.info/sct"/>
            <code value="275711006"/>
            <display value="Chemistry"/>
        </coding>
    </category>
...

Ardon Toonstra (Oct 16 2019 at 12:08):

@Grahame Grieve , @Lloyd McKenzie , could you have a look at the instance provided by Alexander? How should this be discriminated?

Currently, if we create a ValueSet that only contains the fixed code (49581000146104 - Laboratory test finding) and bind this in the profile, the validator would be satisfied and capable of proper validation. It is however very cumbersome to create a ValueSet for one fixed value. We rather would like a validator to be capable to handle both options with a $this discriminator. Or is this impossible?

Grahame Grieve (Oct 16 2019 at 12:38):

it's still on my todo list. I'm trying to catch up

Noemi Deppenwiese (Oct 17 2019 at 12:59):

I have a similar problem: I defined an extension with a CodeableConcept Value and now want to have three slices of coding which each bind to different ValueSets. I used system and version as slicing discriminators and have set the cardinality of system to 1..1 in each slice, but I still get an Error from the validator:

Error @ Specimen.extension[2].value.ofType(CodeableConcept).coding[0] (line 31, col17) : Could not match any discriminators ([system, version]) for slice Extension.value[x].coding:icd-10-gm in profile https://fhir.bbmri.de/StructureDefinition/SampleDiagnosis - None of the discriminator [system, version] have fixed value, binding or existence assertions

Is this a validator bug or an issue with my slicing?

Lloyd McKenzie (Oct 17 2019 at 15:12):

What is your discriminator? It should be "$this" and the discrimination type should be by value

Ardon Toonstra (Oct 22 2019 at 14:08):

Update: the .NET validator is capable of handling this kind of slices if the fixed values are given on the coding level. Not if the fixed values are given in the coding.system and coding.value ect. When the discrimination is of ype value and $this is used on the coding itself.

Ardon Toonstra (Oct 22 2019 at 14:10):

Should a validator be smart enough to walk into the child elements if no fixed coding is given?

Ardon Toonstra (Oct 23 2019 at 14:25):

Another update…

Unfortunately, the fixed coding or fixed codeableConcept does not work because we cannot fix coding.display. Our implementers should be able to use translated display values or other values than we specify. Too bad, the validator will not match a slice that contains a coding.display to the slicing definition, resulting in an error.

<element id="Observation.category">
<path value="Observation.category"/>
 <slicing>
 <discriminator>
<type value="value"/>
<path value="$this"/>
</discriminator>
<rules value="open"/>
</slicing>
<min value="1"/>
</element>
 <element id="Observation.category:LaboratoryTestResultCode">
<path value="Observation.category"/>
<sliceName value="LaboratoryTestResultCode"/>
<short value="LaboratoryTestResultCode"/>
<min value="1"/>
<max value="1"/>
 <fixedCodeableConcept>
 <coding>
<system value="http://snomed.info/sct"/>
<code value="49581000146104"/>
</coding>
</fixedCodeableConcept>
</element>

Ardon Toonstra (Oct 23 2019 at 14:26):

Therefore, we now believe a validator should be smart enough to use the fixed values in the child elements. Do you agree?

Lloyd McKenzie (Oct 23 2019 at 14:27):

Have you considered using pattern?

Ardon Toonstra (Oct 23 2019 at 14:37):

Hi Lloyd, Thanks for your reply!

If we use pattern, we have to set the discriminator type to pattern as well right? How does that work with the ValueSet bindings?

Ardon Toonstra (Oct 23 2019 at 14:39):

Just tried with pattern slicing --> then the .NET validator expects all slices to contain a pattern. Does not work with ValueSet binding

Ardon Toonstra (Oct 23 2019 at 14:46):

Ah, good news, the java validator works well with the pattern and the valueset binding :) thnx

Ardon Toonstra (Oct 23 2019 at 15:28):

Mm, I could also have read the spec somewhat better: http://hl7.org/fhir/profiling.html#discriminator

Grahame Grieve (Oct 24 2019 at 20:32):

well, the page implies that you can't mix pattern and binding (in spite of it working with the validator). Do you have a use case for that?

Ardon Toonstra (Oct 25 2019 at 11:41):

Mm, like Marco mentioned in this zulip chat I can also read that a slice could have a fixed or pattern or binding.

The use case for having a pattern and a valueset binding is described above with the given examples, isn't it? We use a (fixed) category slice to search and index and another category slice with a valueset binding to give a more specific category for the resource, based on a value out of a valueset

Ardon Toonstra (Oct 28 2019 at 15:14):

The attached image shows our current idea on how to profile the above-mentioned use case (simplistic exame, e.g. removed descriptions and cardinalities ect.). What do you think?
Descriminator-example.png

Grahame Grieve (Nov 13 2019 at 23:39):

let's talk about this next week

Ardon Toonstra (Nov 15 2019 at 11:41):

Great, we will do that and let's include @Alexander Henket

Alexander Zautke (Feb 07 2020 at 00:55):

@Ardon Toonstra @Grahame Grieve Has there been a decision on this issue? I have the same use case for Observation.category (pattern slice for fixed values and one additional slice with a required binding).

Ardon Toonstra (Feb 28 2020 at 14:13):

The use case is real. More info in this Zulip chat: https://chat.fhir.org/#narrow/stream/179280-fhir.2Finfrastructure-wg/topic/Is.20there.20a.20difference.20between.20value.20or.20pattern.20slicing.3F

Grahame Grieve (Apr 22 2020 at 05:19):

looks like we haven't close this out - this coming week on FHIR-I? @Ardon Toonstra

Ardon Toonstra (Apr 22 2020 at 12:30):

@Grahame Grieve , is this about the backwards-incompatible notion made by Ewout in https://jira.hl7.org/browse/FHIR-25206? Or about something else?

Grahame Grieve (Apr 22 2020 at 12:30):

oh yes I think that is. So it's closed now?

Ardon Toonstra (Apr 22 2020 at 12:41):

I think this one is closed then. I am happy with the resolution and the upcoming change for the .net API. WildFHIR made adjustments to the validator as well. Still need to correct/update our profiles though.

Ardon Toonstra (Apr 22 2020 at 12:41):

This issue thread is at least related to that JIRA ticket.

Last updated: Apr 12 2022 at 19:14 UTC

Main menu

FHIR Chat · Slicing and value sets · conformance

Stream: conformance

Topic: Slicing and value sets

Grahame Grieve (Aug 04 2019 at 23:41):

Grahame Grieve (Aug 04 2019 at 23:41):

Grahame Grieve (Aug 04 2019 at 23:41):

Grahame Grieve (Aug 04 2019 at 23:41):

Grahame Grieve (Aug 04 2019 at 23:42):

Grahame Grieve (Aug 04 2019 at 23:42):

Grahame Grieve (Aug 04 2019 at 23:42):

Grahame Grieve (Aug 04 2019 at 23:44):

Grahame Grieve (Aug 04 2019 at 23:44):

Grahame Grieve (Aug 04 2019 at 23:45):

Richard Townley-O'Neill (Aug 04 2019 at 23:57):

Grahame Grieve (Aug 04 2019 at 23:59):

Grahame Grieve (Aug 04 2019 at 23:59):

Richard Townley-O'Neill (Aug 05 2019 at 00:01):

Grahame Grieve (Aug 05 2019 at 00:01):

Richard Townley-O'Neill (Aug 05 2019 at 00:04):

Grahame Grieve (Aug 05 2019 at 00:06):

Alexander Henket (Aug 05 2019 at 00:17):

Alexander Henket (Aug 05 2019 at 00:17):

Grahame Grieve (Aug 05 2019 at 00:17):

Alexander Henket (Aug 05 2019 at 00:23):

Grahame Grieve (Aug 05 2019 at 00:27):

Rob Hausam (Aug 05 2019 at 00:27):

Grahame Grieve (Aug 05 2019 at 00:27):

Grahame Grieve (Aug 05 2019 at 00:27):

Lloyd McKenzie (Aug 05 2019 at 01:14):

Grahame Grieve (Aug 05 2019 at 02:43):

Grahame Grieve (Aug 05 2019 at 02:43):

Grahame Grieve (Aug 05 2019 at 05:41):

Ardon Toonstra (Aug 06 2019 at 11:04):

Ardon Toonstra (Aug 06 2019 at 11:05):

Ardon Toonstra (Aug 06 2019 at 11:06):

Ardon Toonstra (Aug 06 2019 at 11:58):

Rob Hausam (Aug 06 2019 at 11:59):

Grahame Grieve (Aug 06 2019 at 13:52):

Grahame Grieve (Aug 06 2019 at 13:53):

Rob Hausam (Aug 06 2019 at 14:53):

Rob Hausam (Aug 06 2019 at 15:03):

Michel Rutten (Aug 06 2019 at 15:05):

Rob Hausam (Aug 06 2019 at 15:07):

Rob Hausam (Aug 06 2019 at 15:08):

Rob Hausam (Aug 06 2019 at 15:10):

Michel Rutten (Aug 06 2019 at 15:39):

Grahame Grieve (Aug 06 2019 at 21:01):

Rob Hausam (Aug 07 2019 at 02:50):

Rob Hausam (Aug 07 2019 at 02:52):

Grahame Grieve (Aug 07 2019 at 02:55):

Rob Hausam (Aug 07 2019 at 03:02):

Grahame Grieve (Aug 07 2019 at 06:18):

Martijn Hermans (Aug 07 2019 at 12:20):

Martijn Hermans (Aug 07 2019 at 12:21):

Martijn Hermans (Aug 07 2019 at 12:22):

Martijn Hermans (Aug 07 2019 at 12:23):

Rob Hausam (Aug 07 2019 at 12:26):

Rob Hausam (Aug 07 2019 at 12:46):

Michel Rutten (Aug 07 2019 at 13:21):

Grahame Grieve (Aug 07 2019 at 13:22):

Michel Rutten (Aug 07 2019 at 13:30):

Ardon Toonstra (Aug 08 2019 at 12:10):

Ardon Toonstra (Oct 11 2019 at 13:19):

Lloyd McKenzie (Oct 11 2019 at 14:36):

Grahame Grieve (Oct 11 2019 at 16:44):

Lloyd McKenzie (Oct 11 2019 at 16:47):

Rob Hausam (Oct 11 2019 at 18:39):

Alexander Henket (Oct 14 2019 at 08:24):

Ardon Toonstra (Oct 16 2019 at 12:08):

Grahame Grieve (Oct 16 2019 at 12:38):

Noemi Deppenwiese (Oct 17 2019 at 12:59):

Lloyd McKenzie (Oct 17 2019 at 15:12):

Ardon Toonstra (Oct 22 2019 at 14:08):

Ardon Toonstra (Oct 22 2019 at 14:10):

Ardon Toonstra (Oct 23 2019 at 14:25):

Ardon Toonstra (Oct 23 2019 at 14:26):

Lloyd McKenzie (Oct 23 2019 at 14:27):

Ardon Toonstra (Oct 23 2019 at 14:37):

Ardon Toonstra (Oct 23 2019 at 14:39):