tag:blogger.com,1999:blog-733074358901582680.post4138313213516325886..comments2024-03-23T05:28:35.472-04:00Comments on Healthcare Standards: Standards Conformance Terminology across IHE, HITSP and HL7Keith W. Boonehttp://www.blogger.com/profile/16883038460949909300noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-733074358901582680.post-28494154782872187112011-01-11T16:46:42.116-05:002011-01-11T16:46:42.116-05:00Note that R2 is a very specific reaction to vendor...Note that R2 is a very specific reaction to vendors/applications/services that would have the value, but pass it in a private-data-element. Thus the data would be passed but in a way that was NOT helpful. So it is a signal to senders that if they don't have it, they don't have to figure out how to get it. This was critical allowance for some UI challenged embedded medical-device.<br /><br />So, R2 is a way of saying that a sender SHALL NOT -NOT- send it in the defined way if they have it. Double negative in this case is a positive. <br /><br />The receiver should not expect it. So the receiver has to handle it as if it was totally optional.<br /><br />But a sender/publisher SHOULD include it while at the same time saying they SHALL NOT send any other way and SHALL NOT -not- send it if they have it. <br /><br />Note: My understanding of IHE regarding not having a value is that they expect the underlying standard to be clear if the value is sent as a null flavor or simply not included. Usually IHE doesn't need to add clarity to this factor, it is usually clear in the underlying standard.John Moehrkehttps://www.blogger.com/profile/04526719420117446030noreply@blogger.comtag:blogger.com,1999:blog-733074358901582680.post-50948657558818856942011-01-11T15:31:17.346-05:002011-01-11T15:31:17.346-05:00Was UCUM also a topic there?Was UCUM also a topic there?Werner Keilhttps://www.blogger.com/profile/00760260299716734104noreply@blogger.com