PHER Issues Table - 2006-09
Return to Category:Referred Reconciliation Issues
This is the Set of the Issues forwarded from RR (PHER SIG) to Methodology and Modeling between May and September, 2006.
| Item ID | Source | Level | Issue | Proposed Disposition |
|---|---|---|---|---|
| LB 1 | Richard HARDING | Neg-Mj | The names of classes that appear in the RMIM diagram change unpredictably when they are displayed in the Table View and Excel Views and in the Schema.
Eg Diagram shows a class "pertainsTo" which is "PertinentInformation" in the Table Excel and schema. In this instance the problem is confounded by how the hyperlink works - go to the diagram and follow the pertainsTo hyperlink, you do not see anything similar on the target page. This is the "Dick's Name Change problem" which I have ballotted at many previous ballot cycles. I note that your RMIM walkthroughs recognise this phenomenon. Please make these names consistent among all views. In my experience it upsets new readers considerably. |
This is a summary of the resolution M&M proposes to adopt.
M&M voted to include this line item (and others below) into the ballot response that responds to LB issue # 106 in Lab Issues Table - 2006-09. For completeness of this table, the specific response is repeated here: M&M voted to recommend to the referring committee that they find this negative vote "Not Persuasive." The reason for this recommendation is expressed in Reconciliation Rationale - 2006-09-29-001. Further, with regard to this concern, M&M agreed to seek improvement in the representation to ease this confusion. This is detailed in Reconciliation Undertaking - 2006-09-29-001. |
| LB 2 | Richard HARDING | Neg-Mj | Similarly "fulfillment" becomes "InFulfillmentOf2".
None of your classes in the RMIM diagram retain their case-sensitive names in the Table, excel and schema views. This is the "Dick's Name Change problem" which I have ballotted at many previous ballot cycles. Please make these names consistent among all views. |
This is a summary of the resolution M&M proposes to adopt.
M&M voted to include this line item (and several others below) into the ballot response that responds to LB issue # 106 in Lab Issues Table - 2006-09. (Also, see above.) |
| LB 3 | Richard HARDING | Neg-Mj | Please conduct a committee vote about whether this dual-name behaviour is acceptable.
Report the result of this vote to MnM Tooling and the balloter. Refer this matter to MnM Tooling. Because of the large number of times I have balloted this matter and received no response, I intend to take the "Paul Biron approach" with this ballot - I will not withdraw my negative on this item without greater assurance that the matter identified has been fixed. |
This is a summary of the resolution M&M proposes to adopt.
M&M voted to include this line item (and several others below) into the ballot response that responds to LB issue # 106 in Lab Issues Table - 2006-09. (Also, see above.) |
| LB 4 | Richard HARDING | Neg-Mj | Excel Views, Table View, schema view, and RMIM diagram for the same HMD each present substantially different information. Which one is the definitive Normative view? Where is that documented?
This has been balloted many times in various domains but I am yet to get a response to this question. |
This is a summary of the resolution M&M proposes to adopt.
M&M finds this item "Not related" because even though it is cast as a negative vote, it poses a direct question about normative status. In response to the voter's question, M&M repeats the position it has always taken, that the abstract HMD is the normative artifact. This expressly excludes both:
Both the Excel View and the Table View are intended to fully represent the HMD. The Excel view is preferred because it expressly displays the serialization of the serialized static model. The serialization can be unequivocally determined from the contents of the Table View, but the sequence is not expressly displayed as it is in the Excel view. M&M intends that the content of the Table View and the Excel view be identical. As the voter points out in the following item, attribute default values are currently missing (erroneously) from the Excel view. See item # 5 below for the proposal relative to this. |
| LB 5 | Richard HARDING | Neg-Mj | Default values must appear on Excel Views - they are currently shown on TableViews.
Fixed values (as shown on the table view) must be adequately highlighted on the Excel View. Bob Dolin has an outstanding ballot item on this one from January 2005 (well over one year ago) that complained of this in the PA domain. The problem is not with Lab it is with Tooling / Publishing. Note also another comment in this ballot where I identify that Fixed and Default do not seem to be defined in the Vocabulary documentation, or V3 Guide. I intend to take the "Paul Biron approach" with this ballot - I will not withdraw my negative on this item without greater assurance that the matter identified has been fixed. |
This is a summary of the resolution M&M proposes to adopt.
M&M voted to recommend to the referring committee that they find this negative vote "Not Related" to the ballot content of the domain being balloted. M&M agrees that the default value should appear in the Excel View, which currently lacks a column for displaying it and will seek a tooling correction from Tooling Committee. |
| LB 7 | Richard HARDING | Neg-Mj | This Topic has no attribute-level descriptions in the Table and excel Views where they are most readily usable.
Indeed I am unable to find attribute-level descriptions for any data item. I note that all of our competitors (RosettaNet, CEN, IHE even V2) all have quite extensive attribute-level descriptions where they are easily accessible. I have balloted this consistently since second ballot in various domains - that is twelve ballot cycles. To date tooling has not provided an adequate tool for this. I intend to take the "Paul Biron approach" with this ballot - I will not withdraw my negative on this item without greater assurance that the matter identified has been fixed. |
This is a summary of the resolution M&M proposes to adopt.
M&M voted to include this line item (and others below) into the ballot response that responds to LB issue # 113 in Lab Issues Table - 2006-09. For completeness of this table, the specific response is repeated here: M&M voted to recommend to the referring committee that they find this negative vote "Not related." This issue was drawn from a domain ballot but it expressly addresses tooling for line item descriptions. Despite this recommendation, however, M&M notes that Tooling has made the requisite changes. This observation should not be construed as agreement by M&M that all attributes must have line-item descriptions. |
| LB 8 | Richard HARDING | A-Q | Please conduct a committee vote about whether the lack of attribute-level descriptions is acceptable in your domain.
Report the result of this vote to MnM Tooling and the balloter. Refer this matter to MnM Tooling. Because of the large number of times I have balloted this matter and received no response, I intend to take the "Paul Biron approach" with this ballot - I will not withdraw my negative on this item without greater assurance that the matter identified has been fixed. |
M&M deferred action as this was not a negative vote, and because the PHER SIG had held the requested vote as documented in the following disposition.
Vote on need for attribute level descriptions. The committee feels it is highly desirable to have attribute level documentation, but current tooling does not adequately support this. When tooling does support it, the committee does will strive to add appropriate attribute level documentation. F-6, O-0, A-0. |
| LB 11 | Austin Kreisler | A-S | At the latest RIM harmonization it was determined that Organizations should never "play" the role of a performer. The InvestigationRequest and InvestigationPromise both allow the R_AssignedOrganization to be the performer of an investigation. This needs to be changed, probably by separating the author participation from the performer participation. The may be a person or an organization. The performer is only a person. | M&M deferred action as this was not a negative vote, but recognizes the concern expressed by PHER in the following.
MnM has created situation where we can't resolve this issue. We need to get resolution to this issue from MnM. |
| LB 12 | Austin Kreisler | A-S | At the latest RIM harmonization it was determined that Organizations should never "play" the role of a performer. The A_PublicHealthStatement model currently uses the R_AssignedEntity CMET to handle the performer, which means an organization can be the performer. This needs to be changed to use the R_AssignedDevice and the R_AssignedPerson CMETs which can be the performers. Probably need to look at creating a R_AssignedLivingSubject CMET also (doesn't exist today). | M&M deferred action as this was not a negative vote, but recognizes the concern expressed by PHER in the following.
MnM has created situation where we can't resolve this issue. We need to get resolution to this issue from MnM. |
| LB 6 | Richard HARDING | A-Q | CONCEPT OF FIXED AND DEFAULT CODED VALUES.
What behaviour do we expect of a sender when valuing an attribute defined as {CNE:IRCP, default= "IRCP"} where the default value is a Specialised term? This appears in POLB_HD004000. I am sure that other examples exist. Do we expect the user to select the most appropriate child of IRCP? That imposes some difficult responsibilities on the receiver. If this is so, will all receiving applications be programmed to correctly interpret this? I suspect this behaviour is unsafe. Do we expect the user to always use IRCP and never select a child? That implies that the value is fixed and the word "default" should actually be "fixed". Do we expect either IRCP or its children will be used? I find this to be unsafe as well. Where is any of this documented? The words "default and "fixed" do not appear in either the RIM or Vocabulary documents. |
M&M deferred action as this was not a negative vote, but recognizes the concern expressed by PHER in the following.
We believe this needs to be disposed of by MnM. The balloter doesn't understand how this should work, and we don't know where this is documented. |
