FHIR Chat · Profile & Logical Model naming · australia

Stream: australia

Topic: Profile & Logical Model naming


view this post on Zulip Stephen Royce (Jun 23 2016 at 07:11):

I assume that we have to create profiles and logical models with unique names, i.e. we can't have a logical model named AllergyIntolerance even though it's kind would have a different value.

view this post on Zulip Stephen Royce (Jun 23 2016 at 07:13):

Given that, is there a naming scheme that is recommended, e.g. <OrgName>-<ResouceName>-<Qualifier>? (I presume we'd need qualifiers of some sort to distinguish between to profiles on the same resource.)

view this post on Zulip Grahame Grieve (Jun 23 2016 at 07:37):

names are not required to be unique, though it's more useful if you scope your name so that it's likely to be

view this post on Zulip Grahame Grieve (Jun 23 2016 at 07:38):

you might make uniqueness rules for your own use of names.

view this post on Zulip Stephen Royce (Jul 21 2016 at 03:08):

So I just realised that I used poor terminology in my question and the response does not actually answer my question (probably). When I said "name", what I meant was the value of the id element of a StructureDefintion.

view this post on Zulip Grahame Grieve (Jul 21 2016 at 04:36):

yes your id should be unique

view this post on Zulip Stephen Royce (Jul 21 2016 at 06:00):

So I cannot create a StructureDefinition with <id value="AllergyIntolerance" /> even if it's a logical model because such a StructureDefinition already exists.

view this post on Zulip Stephen Royce (Jul 21 2016 at 06:03):

To what degree does it need to be unique? Can I, for example infer that "AllergyIntolerence" is unique because it's definition resides at a different URL, say http://electronichealth.net.au/fhir/StructureDefinition/AllergyIntolerence? And I assume that this means that I cannot have a logical model and a resource profile that both have the same id, say "AdverseReaction"?

view this post on Zulip Grahame Grieve (Jul 21 2016 at 06:31):

the logical id does only need to be unique for the local server. The canonical url needs to be globally unique

view this post on Zulip Stephen Royce (Jul 21 2016 at 06:46):

Yeah, but I'm guessing, when it comes to StructureDefinitions at least, it doesn't really make sense to have anything other than a 1:1 relationship between values of id and url?

view this post on Zulip Grahame Grieve (Jul 21 2016 at 06:48):

the implementation guide publisher enforces that

view this post on Zulip Stephen Royce (Jul 21 2016 at 06:52):

Right, so I do need an "ID naming" system to allow me to distinguish between our logical models, profiles of resources and the foundation resources. :(

view this post on Zulip Grahame Grieve (Jul 21 2016 at 06:56):

yes. you should do that

view this post on Zulip Grahame Grieve (Jul 21 2016 at 06:57):

you aren't in the same namespace as the foundation resources, so you don't need to worry about them (you can't define things in http://hl7.org/fhir)

view this post on Zulip Stephen Royce (Jul 21 2016 at 06:59):

Also, is there any guidance on ReST URLs? I was thinking to distinguish between logical StructureDefinitions and resources StructureDefinitions (profiles) in the URL like .../fhir/lm/StructureDefinition/<Structure Definition ID> and .../fhir/rs/StructureDefinition/<Structure Definition ID>, or .../fhir/StructureDefinition/lm/<StructureDefinition ID> and .../fhir/StructureDefinition/rs/<Structure Definition ID>. The latter makes life a bit easier from an ID naming system, but are URLs like this frowned upon? Should I really be looking at just .../fhir/StructureDefinition/<Structure Definition ID>?

view this post on Zulip Grahame Grieve (Jul 21 2016 at 07:01):

well, not so much 'frowned on' - they're legal, but they want be able to hosted in a FHIR RESTful API server if you use URLs like that, and we think that will prove problematic

view this post on Zulip Stephen Royce (Jul 21 2016 at 07:02):

Right, so the "lm" bit needs to be included in the ID? :disappointed:

view this post on Zulip Grahame Grieve (Jul 21 2016 at 07:03):

yes

view this post on Zulip Stephen Royce (Jul 21 2016 at 07:03):

That is .../fhir/StructureDefinition/lm-<Rest of Structure Definition ID>?

view this post on Zulip Grahame Grieve (Jul 21 2016 at 07:03):

you have '-' and '.' as separator characters - they're no less effective than '/'

view this post on Zulip Stephen Royce (Jul 21 2016 at 07:03):

That makes for _ugly_ IDs!

view this post on Zulip Stephen Royce (Jul 21 2016 at 07:04):

Yeah, but with our eXist database, I can use "/lm" to point to a different part of the database more easily.

view this post on Zulip Grahame Grieve (Jul 21 2016 at 07:05):

well, ugly is in the eye of the implementer

view this post on Zulip Stephen Royce (Jul 21 2016 at 07:06):

Indeed. I would have liked the value of the id element to have been scoped by the value of the kind element I suppose, but it doesn't really matter.

view this post on Zulip Stephen Royce (Aug 30 2016 at 01:12):

Another question on this: would you expect the value of StructureDefinition.name (and DataElement.name) to contain spaces?

view this post on Zulip Grahame Grieve (Aug 30 2016 at 01:12):

yes

view this post on Zulip Stephen Royce (Aug 30 2016 at 01:14):

Also, how hard and fast should the practice of StructureDefinition.url = <FHIR Server>/StructureDefinition/[StructureDefinition.id] be?

view this post on Zulip Stephen Royce (Aug 30 2016 at 01:16):

I ask because part of me would like to use our OIDs as StructureDefinition.id, but that would make for really obscure URLs. :disappointed:

view this post on Zulip Grahame Grieve (Aug 30 2016 at 01:17):

well, that depends. What are you going to make the url?

view this post on Zulip Grahame Grieve (Aug 30 2016 at 01:17):

you should put your oid in StructureDefinition.identifier

view this post on Zulip Stephen Royce (Aug 30 2016 at 01:21):

That's what I've started doing, and using values like "lm-AdverseReaction" for StructureDefinition.id. But names like that suck as IDs. :confused:

view this post on Zulip Stephen Royce (Aug 30 2016 at 01:25):

Also, ideally, I'd like to lose the "lm-" prefix in the URL.

view this post on Zulip Stephen Royce (Aug 30 2016 at 01:27):

Also, for StructureDefinition.id, I can coalesce the OID into a single number because the leading part is infered by StructureDefinition and the trailing part is versioning. So the Adverse Reaction StructureDefinition could have an id of just "9", for example. But a URL of "http://digitalhealth.gov.au/fhir/StructureDefinition/9" is probably not that helpful. Mind you, that's what you'd get for Patient, so maybe it's not all bad?

view this post on Zulip Grahame Grieve (Aug 30 2016 at 01:39):

why do you have lm-?

view this post on Zulip Stephen Royce (Aug 30 2016 at 01:43):

Because, in theory, there may be another model whose name is also "AdverseReaction". For instance, what might we call the resource profile derived from the AdverseReaction logical model? Likely, it will be something like "dh-AllergyIntolerance", but we may end up wanting to use our name instead of FHIR's.

view this post on Zulip Stephen Royce (Aug 30 2016 at 01:44):

...whose id is also "AdverseReaction"...

view this post on Zulip Stephen Royce (Aug 30 2016 at 01:46):

I'm trying hard here to get StructureDefinition.id, StructureDefinition.name and StructureDefinition.url to all line up no matter what the value of StructureDefinition.kind, but it doesn't seem possible.

view this post on Zulip Stephen Royce (Aug 30 2016 at 01:50):

And the fact that we want to hand over custodianship of the ultimate resource profiles to HL7 Australia complicates matters enormously. :scream:

view this post on Zulip Grahame Grieve (Aug 30 2016 at 02:05):

I think that you're going to have a cascade of related kinds of models.

view this post on Zulip Stephen Royce (Aug 30 2016 at 02:36):

Yes, we will. We'll have full-blown models that probably contain more than anyone will want for some time which are then constrained at many levels, right down to some idea of core or minimum. And all of then will need to share the same name somehow. I assume, we'll therefore need a system of prefices and suffices to give some idea of shared DNA of the models.

view this post on Zulip Stephen Royce (Aug 30 2016 at 02:39):

So I've started with a prefix of "lm-" for logical model. The set of logical models is likely to be a lot smaller, although that will depend on whether we set up SCSs as an aggregation and constraint of logical models (to enforce consistency) as we currently do or as independent models which share no relationship to each other except as maintained in the head(s) of the modeller(s).


Last updated: Apr 12 2022 at 19:14 UTC