Talk:FHIR Profile Page

Old Comments from Lloyd

• I challenge whether "evidence" is in the 80%. Same for endorser. It might be used for some types of template systems, but a lot of profiling will be done that won't care about these things
  • GG: these were just copied from old templates DSTU in a hurry. Need to reconcile with this also: Template Requirements. See FHIR Profile Metadata
  • LM: Now dropped

• suggest changing name of Profile.profile to Profile.imports. That would be consistent with the naming of "supercedes" which also references profiles
  • GG: different kind of consistency, but I think it's good to avoid Profiles.profile; See FHIR Profile Metadata
  • LM: Renamed to Profile.import

• doesn't resourceType need to allow for "custom" resources too?
  • GG: umm doesn't it? umm, why should it?
  • LM: We need an outlet for those who need resources that aren't (yet) defined by HL7. We had talked about having a base "resource" that would do this - everything in it would be extensions. Perhaps that's all that's needed. The "type" of resource would be handled by the profile.
  • further discussion about at: The Resource With No Name

• I think xpath needs to be broken into a structure which includes xpath and human text
  • Need this to generate schematron output which has to be human readable
  • In some cases, xpath won't be able to do the job - e.g. vocab subsumption.
  • GG: xpath needs to be able to do vocab subsumption, and it's usually done by integrating with a web based service. Why not do this?
  • LM: We probably will define some sort of x-path function that'll do that. Keith B's done some messing around with xPath and CTS. However, the underlying point is "some constraints won't be able to be properly expressed in xPath". Text only is non-computable and therefore bad. But sometimes unavoidable.
  • ok of course
  • see discussion at FHIR conformance and cardinality
  • LM: xpath and English broken out.

• Definitions for mustSupport and mustUnderstand need serious work. Also, you mark them as optional. That implies a default, but one isn't declared anywhere. Do all booleans default to false? Even if so, being explicit would be better
  • GG: agree. better definitions needed. Want to propose some?
  • mustSupport: A conformant system that produces resources instances must be capable of sending data for the element and a conformant system that consumes instances must be capable of taking useful action with the data element (i.e. conformant applications cannot ignore the element)
    • GG: must be capable of sending? In some theoretical construct? Maybe we should say that if mustSupport is true, more clarification of how you must support it, or what cases you must support it?
    • LM: How about: mustSupport: A conformant system that produces resources instances must be capable of populating the element with data and a conformant system that consumes instances must be capable of taking useful action with the data element (i.e. conformant applications cannot ignore the element)
    • LM: The challenge with use-cases is that starts to get into system behavior past the interface, and there could be all sorts of things. We can say something like "Profiles may define more robustly the sources from which an element may be populated or what constitutes "useful action".
  • mustUnderstand: Conformant systems must reject instances containing "mustUnderstand" they do not recognize. "Must understand" extensions can only safely be ignored after a human has inspected the definition of the extension and determined that its impact on the semantics of other resource elements and extensions is not relevant to the purpose of their system.
    • GG: happy with that
  • LM: Definitions were updated

• Which brings up the question of: Should FHIR support defaulting?
  • GG: default question - primitives default. Will add default values in the data types definition.
  • LM: Defaults have been declared

• No clue what you meant by Profile.extensionDefn.contextType
  • GG: you defined the list of options. obviously better definitions are needed
  • LM: Definitions were re-used

• You're inconsistent in how you reference re-used types. For author and endorser, you spell out the content both times. For Profile.resource.element and Profile.extensionDefn.element, you do a funky reference thing.
  • GG: hmm yes. because these are substantial lists of elements shared. Should probably do reuse for endorser - or even better, take it out
  • LM: Endorser was dropped

• • The funky reference thing should do a hyperlink in the HTML. (yes, I know this means you need to put ids on stuff.)
  • GG: will add.
  • LM: Moved to tracker

• Need to define the "may be required" stuff for binding elements.
  • GG: ??
  • LM: A lot of the binding data elements have conditions that say "may be required", but I don't see the rules that define *when* they're required.
  • GG: ?? say like?
  • LM: Profile.binding.code " May be required depending on the value of binding.type". I don't see where we say what binding.type causes the code to be required.
  • LM: Remodelling removed these constraints

• The idea of "must include all the constraints in this profile of referenced profiles" falls down in the face of versioning. If the referenced profile is updated, then what happens? That's one of the points of referencing. I think there needs to be two levels of profiles. Definitional - where constraints haven't been propagated, and Runtime - where they have.
  • GG: long discussion - see here FHIR managing profile identification
  • LM: Remove from here now that discussion is elsewhere

• "The condition element must be present if the conformance value is conditional" - The thing is, the condition may be best stated at a higher level. If the condition is "may have either A or B, but not both", the constraint should appear on the common ancestor of A and B.
  • GG: see here FHIR Conditionality
  • LM: Conditionality was revamped. Conditions can now be attached to multiple elements