This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "FHIR Profile Page"

From HL7Wiki
Jump to navigation Jump to search
 
(7 intermediate revisions by 3 users not shown)
Line 3: Line 3:
 
Back to [[FHIR]]
 
Back to [[FHIR]]
  
−
Comments from Lloyd:
+
== What can be profiled? ==
  
−
* 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
+
At the moment, messaging events and resource search criteria can only be defined at the Resource level.  That means that only HL7 International can define new messaging events (including the base request and response profiles) and only HL7 International can define the search parameters for querying resources.
−
** GG: these were just copied from old templates DSTU in a hurry. Need to reconcile with this also: [[Template Requirements]]. See [[FHIR Template Metadata]]
 
  
−
* suggest changing name of Profile.profile to Profile.imports.  That would be consistent with the naming of "supercedes" which also references profiles
+
* JD - The search page says that ...Each FHIR resource type defines a set of applicable search parameters with their meanings, and '''servers may declare additional parameters in their conformance statements'''.  And the Conformance statement also seems to allow a server to declare additional messaging events.
−
** GG: different kind of consistency, but I think it's good to avoid Profiles.profile; See [[FHIR Template Metadata]]
 
  
−
* doesn't resourceType need to allow for "custom" resources too?
+
* LM - Yes.  And Grahame just re-iterated that search should be specific to Resources only, never in profiles, so . . .
−
** 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.
+
I think this is problematic.  It's going to create extreme strain on the 80% rule.  We don't want to end up with events and search criteria for rare/esoteric use-cases cluttering up the main spec.  At the same time, if we don't provide a mechanism for those things to be defined elsewhere, stakeholders will be well within their rights to have their content defined by HL7 because the requirement exists and they don't want to be non-conformant.
−
** further discussion about at: [[The Resource With No Name]]
+
 
 +
The risk, of course, is that people go off on their own instead of trying to work through HL7 Int'l on content that *should* be coordinated at an international level.  But that's a risk regardless.  And I expect there will be strong incentives to have content "blessed" by HL7 (and maintained by HL7).  Beyond that risk, the only cost to doing this is supporting profile id as part of the data model when we reference events and search criteria.  Events is pretty easy - we just make it a coding instead of a code and use the Profile.id as the system.  It's slightly more painful for search criteria because those show up as REST parameters, but URIs in http parameters are hardly new.
 +
 
 +
... And Grahame wants to know, what are your actual use cases for events that HL7 doesn't need to define, but you need to define. What events are not meaningful enough to influence semenatics, but so meaningful you can't live without them?
 +
* Hard to have examples when I don't know what HL7 will and won't define.  The real question is: Does HL7 Int'l commit to define all possible events implementers find a need for?  If they won't, what alternatives are there than breaking the spec?  We get away with the 80% for resource elements because we define an extension mechanism.  That's the safety valve.  What's the safety valve on the behavioral side?
 +
 
 +
As for search, search turns out to need much more specification. But let's wait for more implementation experience before we change it now
 +
 
 +
== Comments from Lloyd ==
  
 
* Profile.resource.purpose: "Why describe this resource" is weak.
 
* Profile.resource.purpose: "Why describe this resource" is weak.
−
** GG: Specially crossed with the other general metadata. Need a good example, which I'll be working on. See [[FHIR Template Metadata]]
+
** GG: Specially crossed with the other general metadata. Need a good example, which I'll be working on. See [[FHIR Profile Metadata]]
−
 
 
−
* 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]]
 
  
 
* Need to capture the rules about use of "mapping" being a further constraint, not a replacement of.  At least when it applies to RIM.
 
* Need to capture the rules about use of "mapping" being a further constraint, not a replacement of.  At least when it applies to RIM.
Line 31: Line 29:
 
** LM: I'd like to see RIM mapping called out as "special" in resource with the associated notes.  Alternatively just indicate it in notes that mappings do not override, but rather refine mappings from the base resources and higher level profiles.  I.e. A profile cannot do anything that causes a higher level mapping to no longer be true.
 
** LM: I'd like to see RIM mapping called out as "special" in resource with the associated notes.  Alternatively just indicate it in notes that mappings do not override, but rather refine mappings from the base resources and higher level profiles.  I.e. A profile cannot do anything that causes a higher level mapping to no longer be true.
 
** still methodology
 
** still methodology
−
 
−
* 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?
 
−
** 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
 
−
 
−
* Which brings up the question of: Should FHIR support defaulting?
 
−
** GG: default question - primitives default. Will add default values in the data types definition.
 
−
 
−
* No clue what you meant by Profile.extensionDefn.contextType
 
−
** GG: you defined the list of options. obviously better definitions are needed
 
−
 
−
* 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
 
−
 
−
** 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.
 
−
 
−
* 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?
 
−
 
−
* 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]]
 
−
 
−
* "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]]
 
  
 
* Can the same resource be referenced multiple times with different sets of constraints, and if so, what would that mean?  I can think of situations where Person might be referenced in different places with different cosntraints, but if you do that, then you need to be able to say for each resource that references person, which constraint set from within the profile did you want to apply?
 
* Can the same resource be referenced multiple times with different sets of constraints, and if so, what would that mean?  I can think of situations where Person might be referenced in different places with different cosntraints, but if you do that, then you need to be able to say for each resource that references person, which constraint set from within the profile did you want to apply?
 
** GG: see also [[FHIR managing profile identification]]
 
** GG: see also [[FHIR managing profile identification]]
 +
** LM: Profiles now allow the same resource to be profiled in multiple ways, however it's not clear how a particular resource constraint gets referenced when declaring the Type.  It could be this is handled as part of the type.profile, but if so, we need to explain how.  May be cleaner as a separate (optional) element
  
 
* Extension code as the element name won't fly.  Can have multiple extensions with the same name.  You're going to need to be able to alias names in a profile.  And the alias name is what should be used. Element names from codes is a bad scene.
 
* Extension code as the element name won't fly.  Can have multiple extensions with the same name.  You're going to need to be able to alias names in a profile.  And the alias name is what should be used. Element names from codes is a bad scene.
Line 69: Line 38:
 
** LM: I really think you want to allow alias names.  It should be possible for an implementer to create a profile, specify alias names, and have the object model for their app use the names that make sense to them (possibly even in a different language).  Basing names on codes is just a bad idea.
 
** LM: I really think you want to allow alias names.  It should be possible for an implementer to create a profile, specify alias names, and have the object model for their app use the names that make sense to them (possibly even in a different language).  Basing names on codes is just a bad idea.
 
** GG: oh this is about code generation. That's a separate code generation thing then. you don't want that '''in''' the profile
 
** GG: oh this is about code generation. That's a separate code generation thing then. you don't want that '''in''' the profile
 +
** LM: Actually, I do.  I want the rendering for a profile to show the alias, as well.  That way we can use profiles for translations.  And domains can insert their business terms.  And it eliminates the concern over collision of extension codes.

Latest revision as of 16:07, 7 September 2012

Back to FHIR

Back to FHIR discussions / active discussions

This page contains discussion about issues and considerations related to HL7's FHIR specification. When adding content to a page, be sure to uncomment the "Active" category if it is commented (surrounded by <!-- and -->) so that others can notice it and participate too.

Back to FHIR

What can be profiled?

At the moment, messaging events and resource search criteria can only be defined at the Resource level. That means that only HL7 International can define new messaging events (including the base request and response profiles) and only HL7 International can define the search parameters for querying resources.

  • JD - The search page says that ...Each FHIR resource type defines a set of applicable search parameters with their meanings, and servers may declare additional parameters in their conformance statements. And the Conformance statement also seems to allow a server to declare additional messaging events.
  • LM - Yes. And Grahame just re-iterated that search should be specific to Resources only, never in profiles, so . . .

I think this is problematic. It's going to create extreme strain on the 80% rule. We don't want to end up with events and search criteria for rare/esoteric use-cases cluttering up the main spec. At the same time, if we don't provide a mechanism for those things to be defined elsewhere, stakeholders will be well within their rights to have their content defined by HL7 because the requirement exists and they don't want to be non-conformant.

The risk, of course, is that people go off on their own instead of trying to work through HL7 Int'l on content that *should* be coordinated at an international level. But that's a risk regardless. And I expect there will be strong incentives to have content "blessed" by HL7 (and maintained by HL7). Beyond that risk, the only cost to doing this is supporting profile id as part of the data model when we reference events and search criteria. Events is pretty easy - we just make it a coding instead of a code and use the Profile.id as the system. It's slightly more painful for search criteria because those show up as REST parameters, but URIs in http parameters are hardly new.

... And Grahame wants to know, what are your actual use cases for events that HL7 doesn't need to define, but you need to define. What events are not meaningful enough to influence semenatics, but so meaningful you can't live without them?

  • Hard to have examples when I don't know what HL7 will and won't define. The real question is: Does HL7 Int'l commit to define all possible events implementers find a need for? If they won't, what alternatives are there than breaking the spec? We get away with the 80% for resource elements because we define an extension mechanism. That's the safety valve. What's the safety valve on the behavioral side?

As for search, search turns out to need much more specification. But let's wait for more implementation experience before we change it now

Comments from Lloyd

  • Profile.resource.purpose: "Why describe this resource" is weak.
    • GG: Specially crossed with the other general metadata. Need a good example, which I'll be working on. See FHIR Profile Metadata
  • Need to capture the rules about use of "mapping" being a further constraint, not a replacement of. At least when it applies to RIM.
    • GG: where? need a RIM Mappings section in methodology - need a better (and linked) methodology page
    • LM: I'd like to see RIM mapping called out as "special" in resource with the associated notes. Alternatively just indicate it in notes that mappings do not override, but rather refine mappings from the base resources and higher level profiles. I.e. A profile cannot do anything that causes a higher level mapping to no longer be true.
    • still methodology
  • Can the same resource be referenced multiple times with different sets of constraints, and if so, what would that mean? I can think of situations where Person might be referenced in different places with different cosntraints, but if you do that, then you need to be able to say for each resource that references person, which constraint set from within the profile did you want to apply?
    • GG: see also FHIR managing profile identification
    • LM: Profiles now allow the same resource to be profiled in multiple ways, however it's not clear how a particular resource constraint gets referenced when declaring the Type. It could be this is handled as part of the type.profile, but if so, we need to explain how. May be cleaner as a separate (optional) element
  • Extension code as the element name won't fly. Can have multiple extensions with the same name. You're going to need to be able to alias names in a profile. And the alias name is what should be used. Element names from codes is a bad scene.
    • GG: need to explain this better...
    • LM: I really think you want to allow alias names. It should be possible for an implementer to create a profile, specify alias names, and have the object model for their app use the names that make sense to them (possibly even in a different language). Basing names on codes is just a bad idea.
    • GG: oh this is about code generation. That's a separate code generation thing then. you don't want that in the profile
    • LM: Actually, I do. I want the rendering for a profile to show the alias, as well. That way we can use profiles for translations. And domains can insert their business terms. And it eliminates the concern over collision of extension codes.
Retrieved from "https://wiki.hl7.org/w/index.php?title=FHIR_Profile_Page&oldid=65324"