FHIR Chat · Logical Model Instance Validation · conformance

Stream: conformance

Topic: Logical Model Instance Validation

Matt Rouhana (Nov 01 2021 at 14:27):

Is it possible to use the FHIR validator CLI to validate an instance of a logical model against its StructureDefinition? If so, are there any specific content/formatting requirements for the instance? I can't seem to get it to work.

Matt Rouhana (Nov 03 2021 at 17:20):

Anybody have thoughts on the above? I know that Logical Models aren't technically supposed to be instantiated, but it's helpful as a way to persist the requirements of a non-FHIR artifact.

Grahame Grieve (Nov 03 2021 at 17:57):

should be supported as is

Matt Rouhana (Nov 03 2021 at 18:38):

@Grahame Grieve - what should be used as the resourceType of the instantiation?

• Using the name/ID of the logical model or Base yields an error: Fatal @ Base (line 1, col2): This does not appear to be a FHIR resource (unknown name 'Base')
• Using Resource or Element yields errors for each defined field: Error @ Resource (line 4, col23): Unrecognised property '@identifier'
• Not including the resourceType element at all yields yet another error: Fatal @ $ (line 1, col2): Unable to find resourceType property

Oliver Egger (Nov 03 2021 at 19:10):

we had a similar discussion yesterday in the #mapping-framework stream, see post here but we did not yet come up with a solution

Matt Rouhana (Nov 04 2021 at 13:20):

@Oliver Egger - it sounds like it should be supported, per @Grahame Grieve's message above.

Grahame Grieve (Nov 04 2021 at 18:48):

the answer is, it only works for XML...

Grahame Grieve (Nov 04 2021 at 18:48):

I'll add a todo around json for me

Matt Rouhana (Nov 16 2021 at 16:22):

@Grahame Grieve - do you have an estimate of when the above will be available for JSON?

Grahame Grieve (Nov 18 2021 at 01:07):

well, it needs some discussion. In XML, there's a name at the root, and the name (+namespace) indicates what thing it is that is being read (to some degree). I haven't done anything about versioning in the XML logical model thing though - there's a lot of diffferent patterns in use for that

Grahame Grieve (Nov 18 2021 at 01:08):

in json, there's not even any common patterns for name.

Grahame Grieve (Nov 18 2021 at 01:10):

I've seen

• a json object containing a named object, and the name defines what is being read
• a json object with a property that defines it's type. Where the property could be 'type', "_type", "resourceType", "@def", "@definition", "@context"
• a json object where it's just known from some other context what it is

Grahame Grieve (Nov 18 2021 at 01:10):

reading the json is straight forward. It's deciding how to get going, or specifically, how to decide what logical model to use to read a json object, that's the problem to be solved

Chris Moesel (Nov 18 2021 at 13:58):

That's a great point, Grahame -- and one of the reasons we have not yet implemented instances of logical models in SUSHI (since SUSHI is JSON-first). I originally leaned toward using "resourceType" for consistency w/ JSON serialization of FHIR resource instances -- but I also realize that there could be some confusion there since "resource" is kind of an overloaded word in FHIR. It might be nice if processors know that if they see "resourceType" that it conforms to one of the core FHIR resources. So... maybe "logicalType"? It at least has consistent form w/ the existing approach...

Matt Rouhana (Nov 18 2021 at 14:43):

In my mind, a JSON object containing a named object is the most analogous to the XML paradigm:

<my-logical-model xmlns="http://example.org/my-logical-model">
    <name value="Matt" />
    <favorite-color value="orange" />
</my-logical-model>

vs.

{
    "my-logical-model": {
        "name": "Matt",
        "favorite-color": "orange"
    }
}

That being said, this would be less aligned with how FHIR instantiates JSON resources (through the resourceType property).

Oliver Egger (Nov 18 2021 at 14:55):

if you currently convert a xml logical model and write it out to json you get with the java implementation the following:

{
   "resourceType": "my-logical-model",
     "name": "Matt",
     "favorite-color": "orange"
}

Chris Moesel (Nov 18 2021 at 15:49):

LMs are supposed to be identified by their full URL, so I think that whatever it is, it needs to use the full logical URL. The only reason we don't need that for resources (I think) is because the spec indicates that lack of a URL implies a root of http://hl7.org/fhir/StructureDefinition/.

Lloyd McKenzie (Nov 18 2021 at 15:49):

+1 for logicalType as a URI.

Ewout Kramer (Nov 18 2021 at 16:07):

...and a full URI, yes.

Ewout Kramer (Nov 18 2021 at 16:08):

Is there a gap here for dealing with choice types, where the choice is a logical model type? Don't know whether we allow that, but in that case we need something to resolve the type suffix of the choice.

Ewout Kramer (Nov 18 2021 at 16:11):

(and we might need to check whether any of the existing resources use logicalType as a top-level element - but I don't think so)

Chris Moesel (Nov 18 2021 at 16:32):

For choice types you put the full logical URI in the type.code. According to type.code doc (emphasis mine):

URL of Data type or Resource that is a(or the) type used for this element. References are URLs that are relative to http://hl7.org/fhir/StructureDefinition e.g. "string" is a reference to http://hl7.org/fhir/StructureDefinition/string. Absolute URLs are only allowed in logical models.

Ewout Kramer (Nov 18 2021 at 16:37):

But in the instance.....say we have an element valueMyNewLogicalType - the suffix would need to agree with the id/name/last part of the uri?

Chris Moesel (Nov 18 2021 at 17:16):

Oh right. Yeah, I guess that's not as well defined, is it? The documentation on formats says this about choices:

A few elements have a choice of more than one data type for their content. All such elements have a name that takes the form nnn[x]. The "nnn" part of the name is constant, and the "[x]" is replaced with the title-cased name of the type that is actually used. The table view shows each of these names explicitly.

Chris Moesel (Nov 18 2021 at 17:17):

Does that refer to the formal StructureDefinition.name? If so, I guess that is our answer. If not, the tail of the URI makes sense to me.

Grahame Grieve (Nov 18 2021 at 18:28):

StructureDefinition.name

Yes

Ewout Kramer (Nov 19 2021 at 08:19):

That actually might solve another (mostly theoretical) issue I had been toying with: "What is the 'x' in fixed[x] and example[x] referring to when you use a FHIR version 'N' StructureDefinition to express a resource in version 'N+1'"....

Brian Postlethwaite (Nov 19 2021 at 21:41):

Should this be consistent with the custom resources work you did years ago @Grahame Grieve ?

Grahame Grieve (Nov 19 2021 at 22:41):

maybe be that isn't current

Brian Postlethwaite (Nov 20 2021 at 02:26):

I think that the locigal models should be based on context, as noted earlier as one of the options by Grahame further above. One of the commun uses of this could be for mapping existing content, so we can't really force anything inside it.

Matt Rouhana (Dec 01 2021 at 17:08):

Sounds like there are a lot of differing opinions on this topic - how we can move this forward?

Last updated: Apr 12 2022 at 19:14 UTC