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

Difference between revisions of "OO CR138-761 - LWE and LNE Data Types"

From HL7Wiki
Jump to navigation Jump to search
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{OO Open V2.9 Change Requests}}
+
[[Category:OO Accepted V2.8.2 Change Requests]]
 
Return to [[:Category:OO Change Requests|OO Change Requests]] page.
 
Return to [[:Category:OO Change Requests|OO Change Requests]] page.
  
Line 15: Line 15:
  
 
== Issue ==
 
== Issue ==
See [[image:OO CR 138-761.doc]] for problem definition and proposal.
+
See [[image:OO_CR_138-761_-_Updated.docx]] for problem definition and proposal.
  
 
== Recommendation ==
 
== Recommendation ==
Line 22: Line 22:
  
 
== Discussion ==
 
== Discussion ==
Feb 27 204:
+
Feb 27 2014: Review of this CR reveals that the requested datatypes do not seem to be properly defined - we will need ore time for review, but initial thoughts are: How come repeating OBX-5 fields(allowed in the base standard) don't cover this use case? It also is targeting display by receiver, which is not the goal of messaging We do have datatypes for numeric array and multi-axial array however.
Review of this CR reveals that the requested datatypes do not seem to be properly defined - we will need ore time for review, but inital thoughts are:
+
 
How come repeating OBX-5 fields(allowed in the base standard) don't cover this use case?
+
Next steps: Riki to reach out to see, when Clem McDonald can join the call to further discuss this use case. Should OO find this use case needs support, then the document needs to be further fleshed out and should be sent to 1. Vocab WG, because during the v2/v3 tables harmonization project they discovered an issue with including the coding strength in the the dataytpe definition. 2. this is in the end an proposal to InM, as they govern the datatypes
It also is targeting display by receiver, which is not the goal of messaging
+
 
We do have datatypes for numeric array and multi-axial array however.
+
July 10. 2014: suggestion to update the solution to add notes to the solution to describe how we will use OBX-5 repeating to support this use case. Change the verbiage, and provide examples. Riki to update proposal and bring back to committee in a future call
  
Next steps: Riki to reach out to see, when Clem McDonal can join the call to further discuss this use case.
 
Should OO find this use case needs support, then the document needs to be further fleshed out and should be sent to
 
1. Vocab WG, because during the v2/v3 tables harmonization project they discovered an issue with including the coding strength in the the dataytpe definition.
 
2. this is in the end an proposal to InM, s they govern the datatypes
 
 
== Recommended Action Items ==
 
== Recommended Action Items ==
 +
Feb 27 2014: Riki to reach out to see, when Clem McDonald can join the OO WG call to discuss further
  
 
== Resolution ==
 
== Resolution ==
 +
7/31/2014 Motion to accept changes as presented in the above document - David Burgess, Mark Jones, no further discussion, against: 1, abstain: 3, in favor: 12
 +
Against vote was for LRI related change

Latest revision as of 00:02, 1 August 2014

Return to OO Change Requests page.

Submitted by: Clem McDonald Revision date: <<Revision Date>>
Submitted date: 11 September 2013 Change request ID: OO CR138-761
Standard/IG: Standard Artifact ID, Name: <<Artifact ID, Name>>

Issue

See File:OO CR 138-761 - Updated.docx for problem definition and proposal.

Recommendation

Rationale

Discussion

Feb 27 2014: Review of this CR reveals that the requested datatypes do not seem to be properly defined - we will need ore time for review, but initial thoughts are: How come repeating OBX-5 fields(allowed in the base standard) don't cover this use case? It also is targeting display by receiver, which is not the goal of messaging We do have datatypes for numeric array and multi-axial array however.

Next steps: Riki to reach out to see, when Clem McDonald can join the call to further discuss this use case. Should OO find this use case needs support, then the document needs to be further fleshed out and should be sent to 1. Vocab WG, because during the v2/v3 tables harmonization project they discovered an issue with including the coding strength in the the dataytpe definition. 2. this is in the end an proposal to InM, as they govern the datatypes

July 10. 2014: suggestion to update the solution to add notes to the solution to describe how we will use OBX-5 repeating to support this use case. Change the verbiage, and provide examples. Riki to update proposal and bring back to committee in a future call

Recommended Action Items

Feb 27 2014: Riki to reach out to see, when Clem McDonald can join the OO WG call to discuss further

Resolution

7/31/2014 Motion to accept changes as presented in the above document - David Burgess, Mark Jones, no further discussion, against: 1, abstain: 3, in favor: 12 Against vote was for LRI related change