Inferno is validating resources using latest profile version instead of 3.1.1 even when specified in resource

[amcmanus1]

Inferno2.0 is validating resources against the latest profile versions even when a profile version is specified in fhir resources.

So a resource with the following meta will still get validated against latest profile version and not the one specified...
"meta": { "profile": [ "http://hl7.org/fhir/us/core/StructureDefinition/us-core-implantable-device|3.1.1" ] },

When we run the following curl request against our hosted validator we get the error below...
curl --location --request POST 'https://...inferno-core-validator-api/validate?profile=http://hl7.org/fhir/us/core/StructureDefinition/us-core-implantable-device|3.1.1' \ --header 'Content-Type: application/json' \ --data-raw '{ "id": "9879", "meta": { "profile": [ "http://hl7.org/fhir/us/core/StructureDefinition/us-core-implantable-device|3.1.1" ] }, "extension": [ { "url": "https://fhir.athena.io/StructureDefinition/ah-practice", "valueReference": { "reference": "Organization/234234" } }, { "url": "https://fhir.athena.io/StructureDefinition/ah-chart-sharing-group", "valueReference": { "reference": "Organization/234234324" } } ], "udiCarrier": [ { "deviceIdentifier": "00827002008776", "jurisdiction": "http://hl7.org/fhir/NamingSystem/fda-udi", "carrierHRF": "(01)00827002008776" } ], "status": "entered-in-error", "type": { "text": "Peripheral vascular guidewire, manual" }, "patient": { "reference": "Patient/6757" }, "resourceType": "Device" }'

The following error is given by inferno when a valid resource is provided in results...
us-core-9: 'For implantable medical devices that have UDI information, at least one of the Production Identifiers (UDI-PI) SHALL be present.' Rule 'For implantable medical devices that have UDI information, at least one of the Production Identifiers (UDI-PI) SHALL be present.' Failed

[Jammjammjamm]

The validator does not completely handle multiple versions of IGs. For g10 certification, we handle this by only loading a single version of the IG into the validator, and not exposing the validator API.

So in our deployments, the validator app, Inferno Community, and any non-g10 test suites use an instance of the validator which is publicly exposed so that additional IGs can be loaded, while Inferno Program and the (g)(10) suite use a separate validator that isn't publicly exposed and only contains US Core 3.1.1.

[nathanloyer]

We can try that out today as a workaround. Will yall be able to make it so the validator can correctly handle multiple IG versions? Is this an issue whose root cause is in the java validator from the hapi folks?

[yunwwang]

uscore-9 is an invariant in US Core v3.1.1 which is deprecated in US Core v3.2.0. By that means, validator does use the correct US Core version.

[yunwwang]

uscore-9 states "us-core-9: For implantable medical devices that have UDI information, at least one of the Production Identifiers (UDI-PI) SHALL be present."
The resource you provided in the first post does have UDI information - Device.udiCarrier.carrierHRF, but by just glancing the resource, I don't see any UDI-PI element populated.

[yunwwang]

UDI-PI element is defined in US Core Implantable Device profile as

The following parsed Production Identifiers (UDI-PI) from the UDI

• the manufacture date
• the expiration date
• the lot number
• the serial number
• the distinct identifier (i.e., the distinct identification code)

[Jammjammjamm]

Is this an issue whose root cause is in the java validator from the hapi folks?

My investigations indicated that when multiple version of a profile are loaded, the newest versions of Extensions and ValueSets are used regardless of which profile version you're validating against: hapifhir/org.hl7.fhir.core#614

It doesn't seem like there was any interest in fixing that issue.

[nathanloyer]

guess I can try pushing on that thread then

[nathanloyer]

Also we confirmed that just loading the 3.1.1 IG did still generate the issue, backing up Yunwei's comments.

So you called us-core-9 an invariant and noted that it was removed in later versions of the spec. So do we still need to adhere to it for g10 certification?

[yunwwang]

Current g10 certification procedure mandate US Core v3.1.1. So the answer is yes. Server implementation has to conform that invariant.

US Core 3.2/4.0 replaces this invariant with a narrative paragraph which, in my understanding, strengthens current invariant.

Here is the requirement in v3.1.1
us-core-9: For implantable medical devices that have UDI information, at least one of the Production Identifiers (UDI-PI) SHALL be present.

Here is the requirement in v3.2.0/v4.0.0
Implantable medical devices that have UDI information SHALL represent the UDI code in Device.udiCarrier.carrierHRF.
All of the five UDI-PI elements that are present in the UDI code SHALL be represented in the corresponding US Core Implantable Device Profile element.

[nathanloyer]

Doubling down on the request in issue #155, the data provided in the bulk messages and http requests was also insufficient to figure out which resource was failing. We had to build a fake validator service to direct the requests to in order to figure out what was going on.

[nathanloyer]

Turns out the failing resource is actually this one.. but it looks like inferno is removing our data absent reasons before sending it along to the validator.

{
  "extension": [
    {
      "valueReference": {
        "reference": "Organization/234234"
      },
      "url": "https://fhir.athena.io/StructureDefinition/ah-practice"
    },
    {
      "valueReference": {
        "reference": "Organization/234234324"
      },
      "url": "https://fhir.athena.io/StructureDefinition/ah-chart-sharing-group"
    }
  ],
  "resourceType": "Device",
  "_serialNumber": {
    "extension": [
      {
        "url": "http: //hl7.org/fhir/StructureDefinition/data-absent-reason",
        "valueCode": "unknown"
      }
    ]
  },
  "status": "entered-in-error",
  "meta": {
    "profile": [
      "http://hl7.org/fhir/us/core/StructureDefinition/us-core-implantable-device"
    ]
  },
  "_distinctIdentifier": {
    "extension": [
      {
        "url": "http: //hl7.org/fhir/StructureDefinition/data-absent-reason",
        "valueCode": "unknown"
      }
    ]
  },
  "_expirationDate": {
    "extension": [
      {
        "url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
        "valueCode": "unknown"
      }
    ]
  },
  "_lotNumber": {
    "extension": [
      {
        "url": "http: //hl7.org/fhir/StructureDefinition/data-absent-reason",
        "valueCode": "unknown"
      }
    ]
  },
  "patient": {
    "reference": "Patient/6757"
  },
  "_manufactureDate": {
    "extension": [
      {
        "url": "http://hl7.org/fhir/StructureDefinition/data-absent-reason",
        "valueCode": "unknown"
      }
    ]
  },
  "id": "9879",
  "type": {
    "text": "Peripheral vascular guidewire, manual"
  },
  "udiCarrier": [
    {
      "deviceIdentifier": "00827002005112",
      "carrierHRF": "(01)00827002005112",
      "jurisdiction": "http://hl7.org/fhir/NamingSystem/fda-udi"
    }
  ]
}

The request that Alex mentions in the issue description shows how our mocked out validator receives the request.

[nathanloyer]

At @yunwwang's request, we will close this issue and follow up with it in onc-healthit/onc-certification-g10-test-kit#67