This wiki has undergone a migration to Confluence found Here
Difference between revisions of "FHIR Profile Page"
Jump to navigation
Jump to search
(Created page with "Comments from Lloyd: * Example table under slicing is hard to read. Perhaps change content to courier? * I challenge whether "evidence" is in the 80%. Same for endorser. It mi...") |
|||
| Line 1: | Line 1: | ||
Comments from Lloyd: | Comments from Lloyd: | ||
| + | |||
* Example table under slicing is hard to read. Perhaps change content to courier? | * Example table under slicing is hard to read. Perhaps change content to courier? | ||
| + | ** GG: I'll see waht I can do | ||
| + | |||
* 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 | * 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]] | ||
| + | |||
* suggest changing name of Profile.profile to Profile.imports. That would be consistent with the naming of "supercedes" which also references profiles | * 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 | ||
| + | |||
* doesn't resourceType need to allow for "custom" resources too? | * doesn't resourceType need to allow for "custom" resources too? | ||
| + | ** GG: umm doesn't it? umm, why should it? | ||
| + | |||
* 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 | ||
| + | |||
* I think xpath needs to be broken into a structure which includes xpath and human text | * 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 | ** 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. | ** 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? | ||
| + | |||
* 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. | ||
| + | ** GG: where? need a RIM Mappings section in methodology - need a better (and linked) methodology page | ||
| + | |||
* 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 | * 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? | ||
| + | |||
* Which brings up the question of: Should FHIR support defaulting? | * 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 | * 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. | * 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.) | ** 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. | * Need to define the "may be required" stuff for binding elements. | ||
| + | ** GG: ?? | ||
| + | |||
* 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. | * 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. | * "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]] | ||
| + | |||
* 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. | ||
| + | ** GG: need to explain this better... | ||
Revision as of 20:58, 23 May 2012
Comments from Lloyd:
- Example table under slicing is hard to read. Perhaps change content to courier?
- GG: I'll see waht I can do
- 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
- 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
- doesn't resourceType need to allow for "custom" resources too?
- GG: umm doesn't it? umm, why should it?
- 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
- 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?
- 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
- 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?
- 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: ??
- 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?
- GG: see also FHIR managing profile identification
- 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...
