Difference between revisions of "Publishing Facilitators Guide Updates"
Astechishin (talk | contribs) |
Astechishin (talk | contribs) |
||
| Line 1: | Line 1: | ||
==Publishing Facilitators Guide Changes== | ==Publishing Facilitators Guide Changes== | ||
| − | + | ====Remove TBDs from document==== | |
| − | + | Publishing passed a motion on March 5, 2008 setting requirements for RMIM walk-throughs and for attribute-level documentation. The motion is followed by action item "intend to perpetuate this position in the Facilitator's Guide." But, the Guide does not list this as a requirement (and Recommended and Best Practice sections just say TBD) | |
| − | + | ||
| + | ====Request for guidance on '''SHALL'''==== | ||
| + | ''From Charlie Mackay'' | ||
| + | |||
| + | The Continua PHM DSTU points to the publishing facilitators guide for a definition of these terms, and there is a short section in that doucment pointing to the ISO definitions, saying that "SHOULD" indicates best practice. | ||
| + | At some point in the implementation process all of these SHOULDs have to turn into a decision as to whether they are to be followed or not. Maybe some can be left open for runtime decisions. | ||
| + | It seems to me that in the standard we should (or must) provide better guidence in each case to indicate whether this is something that may/should/must be resolved at project level, or may/should/must be left as guidence for the discretion of each implementer. | ||
| + | As I look at compliance of other specifications with the CDA implementation guide, I have to make decisions about these, and some further clarity would be helpful. It would also be useful to provide some support for the person having to make the decision in each case (why SHOULD it be done, and what are the sorts of situations where is MAY not be done) | ||
Revision as of 05:54, 7 May 2010
Publishing Facilitators Guide Changes
Remove TBDs from document
Publishing passed a motion on March 5, 2008 setting requirements for RMIM walk-throughs and for attribute-level documentation. The motion is followed by action item "intend to perpetuate this position in the Facilitator's Guide." But, the Guide does not list this as a requirement (and Recommended and Best Practice sections just say TBD)
Request for guidance on SHALL
From Charlie Mackay
The Continua PHM DSTU points to the publishing facilitators guide for a definition of these terms, and there is a short section in that doucment pointing to the ISO definitions, saying that "SHOULD" indicates best practice. At some point in the implementation process all of these SHOULDs have to turn into a decision as to whether they are to be followed or not. Maybe some can be left open for runtime decisions. It seems to me that in the standard we should (or must) provide better guidence in each case to indicate whether this is something that may/should/must be resolved at project level, or may/should/must be left as guidence for the discretion of each implementer. As I look at compliance of other specifications with the CDA implementation guide, I have to make decisions about these, and some further clarity would be helpful. It would also be useful to provide some support for the person having to make the decision in each case (why SHOULD it be done, and what are the sorts of situations where is MAY not be done)
