FHIR Chat · Abstract Types · methodology

Stream: methodology

Topic: Abstract Types

view this post on Zulip Grahame Grieve (Dec 10 2019 at 04:34):

I have committed an update to build.fhir.org to rebuild the abstract type system. Mostly, this is making explicit what was implicit. The only difference it makes will be to the code generators that now have to mostly undo special case logic they needed for earlier versions

view this post on Zulip Grahame Grieve (Dec 10 2019 at 04:34):

The main change is http://build.fhir.org/types.html

view this post on Zulip Grahame Grieve (Dec 10 2019 at 05:26):

there's one change that MnM aproved that I have not yet made... making MetadataResource explicit in the spec (harder work)

view this post on Zulip Grahame Grieve (Dec 13 2019 at 23:17):

ok I've made the first step of that... making it explicit. but I haven't changed anything to inherit from it yet.

Here's what I think we should do:

  • split it into CanonicalResource and MetadataResource
  • MetadataResource gets approvalDate, lastReviewDate, and effectivePeriod, and CanonicalResource gets the rest
  • the resources CapabilityStatement, StructureDefinition, ImplementationGuide, SearchParameter, MessageDefinition, OperationDefinition, CompartmentDefinition, StructureMap, GraphDefinition, ExampleScenario, CodeSystem, ValueSet, ConceptMap, NamingSystem, TerminologyCapabilities, TestScript and EventDefinition specialize CanonicalResource
  • the resources ActivityDefinition, ChargeItemDefinition, ConditionDefinition, Evidence, EvidenceVariable, Library, Measure, PlanDefinition, and Questionnaire specialize MetadataResource
  • the resources that do not have properties in their generalization get them. In the normative resources, that means:
    • CapabilityStatement gets identifier
    • SearchParameter gets identifier, title, copyright
    • OperationDefinition gets identifier, copyright
  • the resources still all actually define what they have, and CanonicalResource and MetadataResource get some stereotype or something as part of their definition to say that they are extra abstract (just an interface, no properties defined, since there's interspersed properties in their children, and the children redefine bindings, definitions)

view this post on Zulip Lloyd McKenzie (Dec 13 2019 at 23:41):

Philisophically, I'm not thrilled with introducing elements that aren't needed just for the sake of a class model. SearchParameter having title is a good thing - it should already have had. Copyright on OperationDefinition is also reasonable. The others are are very questionable. However, because they're infrastructure and won't impact most implementers, I can hold my nose...

view this post on Zulip Paul Church (Dec 14 2019 at 19:59):

I had been considering making the suggestion to move identifier all the way up to DomainResource, so I'm very happy to see that the spec was already heading somewhat in that direction. I'm looking at use cases involving the server doing resolution of logical references, which is limited if a small minority of resource types don't have identifiers.

view this post on Zulip Grahame Grieve (Dec 14 2019 at 21:33):

we've considered and rejected that several times. But I don't think we've had the discussion in light of the change to reference to add identifier

view this post on Zulip Grahame Grieve (Dec 20 2019 at 02:33):

ok, here's the gaps other than identifier (see other thread about identifiers):

Elements not defined by implied by an interface they claim to implement:

  • ChargeItemDefinition.name [from CanonicalResource]
  • ChargeItemDefinition.purpose [from CanonicalResource]
  • CompartmentDefinition.title [from CanonicalResource]
  • CompartmentDefinition.jurisdiction [from CanonicalResource]
  • CompartmentDefinition.copyright [from CanonicalResource]
  • ConditionDefinition.purpose [from CanonicalResource]
  • ConditionDefinition.copyright [from CanonicalResource]
  • ConditionDefinition.approvalDate [from MetadataResource]
  • ConditionDefinition.lastReviewDate [from MetadataResource]
  • ConditionDefinition.effectivePeriod [from MetadataResource]
  • Evidence.name [from CanonicalResource]
  • Evidence.experimental [from CanonicalResource]
  • Evidence.publisher [from CanonicalResource]
  • Evidence.contact [from CanonicalResource]
  • Evidence.jurisdiction [from CanonicalResource]
  • Evidence.purpose [from CanonicalResource]
  • Evidence.copyright [from CanonicalResource]
  • Evidence.effectivePeriod [from MetadataResource]
  • EvidenceVariable.experimental [from CanonicalResource]
  • EvidenceVariable.purpose [from CanonicalResource]
  • ExampleScenario.title [from CanonicalResource]
  • ExampleScenario.description [from CanonicalResource]
  • GraphDefinition.title [from CanonicalResource]
  • GraphDefinition.copyright [from CanonicalResource]
  • ImplementationGuide.purpose [from CanonicalResource]
  • NamingSystem.title [from CanonicalResource]
  • NamingSystem.experimental [from CanonicalResource]
  • NamingSystem.purpose [from CanonicalResource]
  • NamingSystem.copyright [from CanonicalResource]
  • OperationDefinition.copyright [from CanonicalResource]
  • SearchParameter.title [from CanonicalResource]
  • SearchParameter.copyright [from CanonicalResource]

view this post on Zulip Lloyd McKenzie (Dec 20 2019 at 16:05):

CharegeItemDefinition - seems unlikely to generate code from, so don't understand name. CompartmentDefinition title - ok. Jurisdiction and copyright would be useless - they'd be fixed values. Not a fan of adding anything to Evidence right now. Title and description for ExampleScenario would be good ideas. Title for GraphDefinition is fine. copyright could be an extension. IG purpose is fine. NamingSystem.title - think we've got a change request to add that already. experimental, sure. Purpose is unneeded, as is copyright. OperationDefinition.copyright, sure. SearchParameter.title, sure. SearchParameter.copyright - extension at most

Last updated: Apr 12 2022 at 19:14 UTC


An HL7 Website -