Stream: implementers
Topic: Where are the types of References specified?
Michael Faughn (Oct 30 2018 at 19:10):
When I look at the FHIR specification online I see Resources where attributes are typed as Reference and then the type that is referenced is indicated.
fhir_reference_type.png
When I look at the XSD, I can not find information about what type a Reference refers to.
<xs:complexType name="Device"> <xs:complexContent> <xs:extension base="DomainResource"> <xs:sequence> <!--This does not tell me that it is a reference to a DeviceDefinition --> <xs:element name="definition" minOccurs="0" maxOccurs="1" type="Reference"> <xs:annotation> <xs:documentation xml:lang="en">The reference to the definition for the device.</xs:documentation> </xs:annotation> </xs:element> <!--other attributes elided --> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>
I would like to know where information about what type(s) that References refer to is specified. I'll admit to being neither a XML wizard or having had a thorough look through the build process repo. If anyone could point me to something machine readable I would be grateful.
Jean Duteau (Oct 30 2018 at 19:14):
It won't be on the element but can be contained within the Reference type: http://build.fhir.org/references.html#Reference The Reference.type element can be used to define what type the reference refers to. Note that it is optional 0..1 so it won't always be there.
Jean Duteau (Oct 30 2018 at 19:15):
Here is more information about the reference target type: http://build.fhir.org/references.html#type
Lloyd McKenzie (Oct 30 2018 at 19:20):
The schemas don't differentiate. The "type" of Reference is the same regardless of what the Reference points to. (It's just a URI and possibly a display or business identifier). Enforcement of what can be at the other end of the reference requires resolving the reference, which is something that XML Schema can't manage.
Michele Mottini (Oct 30 2018 at 19:46):
You have to look at the StructureDefinition files to get that information
Lloyd McKenzie (Oct 30 2018 at 21:27):
There are quite a few things (profile assertions, terminology bindings, constraints, "mustSupport", etc. that can't be enforced by the schemas.
Michael Faughn (Oct 31 2018 at 14:28):
OK, let me ask the question a different way. In the example I gave, the definition found on the FHIR website does indicate that the Reference is to an object of type DeviceDefinition. I am assuming that this information is specified somewhere in some format that programmatically consumable and that this source is used to build the definition that we see on the website. Is this assumption correct? If it is correct, then what/where is that source?
Michele Mottini (Oct 31 2018 at 14:34):
It is in the StructureDefinition file - profiles-resources.xml
Michele Mottini (Oct 31 2018 at 14:36):
http://hl7.org/fhir/definitions.xml.zip
Michael Faughn (Oct 31 2018 at 15:07):
Thanks. That does help. The information is parseable from the profiles-resources.xml file.
<element id="Device.definition">
<path value="Device.definition"/>
<short value="The reference to the definition for the device"/>
<definition value="The reference to the definition for the device."/>
<min value="0"/>
<max value="1"/>
<type>
<code value="Reference"/>
<targetProfile value="http://hl7.org/fhir/StructureDefinition/DeviceDefinition"/>
</type>
</element>
This is certainly enough for me to proceed with what I'm attempting to do. I still must wonder though, if one were to add or remove a target for a Reference, is it this file that would be changed manually? I somehow had the impression that structure definitions in this file were themselves generated from other inputs.
Jean Duteau (Oct 31 2018 at 15:14):
Each resource has a source document in the build. That is where the resource author will identify the various elements and their datatypes.
Michel Rutten (Oct 31 2018 at 15:14):
Hi @Michael Faughn, to constrain the reference, you have to create a (separate) "derived profile". You cannot change the definitions of the core FHIR Resources & Datatypes, as this would break compatibility with other FHIR systems.
Michel Rutten (Oct 31 2018 at 15:14):
See http://hl7.org/fhir/profiling.html
Michael Faughn (Oct 31 2018 at 15:45):
So, let's take the source document for the Device resource then. Where can I find that file? Is it in the github repo?
@Michel Rutten I'm not trying to do change anything or create anything new at all. I'm trying to figure out exactly how the information that is in the structure definitions got there. At the moment I'm occupied specifically with how the targetProfile values for attributes that are typed as Reference get included in the structure definitions. I'm trying to develop a process for programmatically building the FHIR spec (or at least as much as I can of it) as instances of the UML metamodel (computable instances, not simply class diagram images). I want to do this with as much fidelity and completeness as I possibly can.
Jean Duteau (Oct 31 2018 at 15:51):
Yes, it is all in the github repository. fhir/source/device/device-spreadsheet.xml
Michel Rutten (Oct 31 2018 at 15:53):
All FHIR datamodels are defined by means of a FHIR StructureDefinition. Definitions for FHIR core resources and datatypes are published as part of the spec (definitions.zip, profiles-resources.xml and profiles-types.xml). These definition files provide a complete and computable description of the spec.
Definitions for user models are typically published to the HL7 FHIR registry (http://registry.fhir.org/) and on Simplifier (https://simplifier.net).
BTW Are you familiar with MDHT (https://github.com/mdht/mdht)? This is a UML-based profiling tool that also supports FHIR.
Lloyd McKenzie (Oct 31 2018 at 16:12):
While the spreadsheets are the source of truth in Github, noone should write tools against them. We may shift authoring tools at some point. The StructureDefinition instances are the "standard" way of expressing the models and are the safest thing to interact with for software.
Michael Faughn (Oct 31 2018 at 16:25):
I've had a look at the device-spreadsheet.xml file. I did find the cell where DeviceDefinition is specified as the target for the Reference that Device.defintion is typed as. Thanks. It's informative. We have done a fair amount of work programmatically generating specifications for standards. There is certainly an element of curiosity in having a look down into the bowels of how FHIR gets put together that is, at some point, beyond any practical need I have. I definitely do not intend to use the spreadsheets as an input for my process. It's clear that the generated files in the definitions.xml.zip collection are the interface I should be working against.
I'm familiar with the MDHT work. We have a fairly extensive UML based toolchain already. It is what I use to do the IEEE 11073 based work. I'm hoping to get some mileage out of having the FHIR model expressed in the same toolchain.
Grahame Grieve (Oct 31 2018 at 20:09):
I'm certainly interested in talking about the conceptual underpinnings for the UML metamodel, and what you intend it to achieve. There's some compromises to make that require careful thought and perspective to strike the right balance
Grahame Grieve (Oct 31 2018 at 20:10):
the structure definitions are the master format. We may transit to using them as the editorial source instead of spreadsheets once they are stable. So they should be the focus. Though I would recommend the json format in the NPM packages, since that it our main commitment going forward
Michael Faughn (Nov 02 2018 at 18:37):
When I've got something banged together I'll share it. It'll help any discussion.
Michael Faughn (Nov 05 2018 at 21:37):
Well, if nothing else, this is certainly a good way to get acquainted with the ins and outs of the Structure Defs. I'm running across a few things that make me scratch my head a bit. I notice that what I see online in the structure doesn't always align with what I find in the downloaded files (xsd and resources-profile.xml). An example of this is Claim.payee. Online it is a backbone element with two attributes, type and party. In the downloaded files there is an additional attribute: <xs:element name="resource" minOccurs="0" maxOccurs="1" type="Coding">. Both sources purport to be v3.6.0. I'm not sure what to do with such situations. Which is correct?
Lloyd McKenzie (Nov 05 2018 at 23:15):
Can you provide the URLs of the files you're looking at?
Michael Faughn (Nov 06 2018 at 02:56):
I downloaded again from here.
My first download includes this in the schema files:
Generated on Thu, Oct 25, 2018 13:08+0000 for FHIR v3.6.0
Todays download includes this:
Generated on Tue, Nov 6, 2018 00:02+0000 for FHIR v3.6.0
Today's download doesn't include the extra attribute. I did not know that I needed to look at version.info to get the complete versioning information. Why is the revision number elided elsewhere?
Grahame Grieve (Nov 06 2018 at 06:39):
3.6.0 is the current build and is rolling over quickly right now - I suspect you got caught by ongoing changes
Last updated: Apr 12 2022 at 19:14 UTC
