tag:blogger.com,1999:blog-733074358901582680.post4862671488672950836..comments2024-03-23T05:28:35.472-04:00Comments on Healthcare Standards: Where do they go? Insurance ID Cards and CCD & CCDAKeith W. Boonehttp://www.blogger.com/profile/16883038460949909300noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-733074358901582680.post-30509377474995200272013-12-06T17:15:34.133-05:002013-12-06T17:15:34.133-05:00Do this instead according to Lloyd's message:
...Do this instead according to Lloyd's message:<br /><br />-id nullFlavor='UNK' extension='Group#'/-<br />-id nullFlavor='UNK' extension='Contract#'/-<br /><br />And you'll be all set.Keith W. Boonehttps://www.blogger.com/profile/16883038460949909300noreply@blogger.comtag:blogger.com,1999:blog-733074358901582680.post-85908023564911481722013-12-06T15:48:20.858-05:002013-12-06T15:48:20.858-05:00Hello how about adding 2 Ids to the
-act cla...Hello how about adding 2 Ids to the <br /> -act classCode='ACT' moodCode='EVN'-<br /><br />Like this..<br /> -id root='2844AF96-37D5-42a8-9FE3-3995C110B4F1'<br /> extension='Group#'/-<br /> -id root='2844AF96-37D5-42a8-9FE3-3995C110B4F2'<br /> extension='Contract#'/-<br /><br />All I would love is 2 standard root ID that everyone would know, but I guess I'll end up using 2 unique OID from my organization. <br /><br />Note: I haven't tested/validated the idea<br />PS: I had to change some characters for the comment to be valid, but I hope you guys get the idea.Anonymoushttps://www.blogger.com/profile/13830385879827439413noreply@blogger.comtag:blogger.com,1999:blog-733074358901582680.post-22820211250734122292012-11-02T14:02:08.244-04:002012-11-02T14:02:08.244-04:00You can get the standard here: http://www.wedi.org...You can get the standard here: <a href="http://www.wedi.org/snip/public/articles/prot/index.cfm?pdfid=3593&ID=1009" rel="nofollow">http://www.wedi.org/snip/public/articles/prot/index.cfm?pdfid=3593&ID=1009</a>. It requires registration, but no payment as far as I can tell.Keith W. Boonehttps://www.blogger.com/profile/16883038460949909300noreply@blogger.comtag:blogger.com,1999:blog-733074358901582680.post-91681980813235441032012-11-02T13:49:35.574-04:002012-11-02T13:49:35.574-04:00A few years back, a colleague looped me into a &qu...A few years back, a colleague looped me into a "3-month" project to produce a health ID card standard. 18 months later, and with the blessings of the various interest groups (including the banking industry, which has an interest in new hybrid insurance/fsa cards), WEDI published a voluntary standard. That design has since been updated, but remains, unfortunately, under a pay wall at the wedi.org site. <br /><br />The issue of machine readability was debated at length. Basically, card issuers (and yes, the DO have an interest in having their members' information represented accurately) were loath to go beyond the meagre mag stripe capacity, since many had invested millions in both the cards themselves, and installing readers in thousands of provider sites in various markets. I, and a few others, posited a PDF bar code alternative, as it accommodated more data (enough to identify the subscriber and any depedents, for instance), and could be captured when a provider scanned the card on the first patient visit.<br /><br />One thing we sorely lacked? A definitive health plan identifier. Now the HPID mandate is on the books, but there is no requirement that it be used on this or any card standard. Much less that the numbers be meaningful in terms of positively identifying the policy issuer.<br /><br />The standard has been updated since I left the scene. Aspects I've described may have changed. But a standard does indeed exist. <br />Marty Jensen, Sr. Analyst (He/His)https://www.blogger.com/profile/15392825140446748765noreply@blogger.comtag:blogger.com,1999:blog-733074358901582680.post-64621210152918925532012-10-31T22:13:07.858-04:002012-10-31T22:13:07.858-04:00Hi Keith,
Sorry. Too small a font on my end :>...Hi Keith,<br /><br />Sorry. Too small a font on my end :><br /><br />The key point is that properly populating a v3 instance if your sole input is a health card is a challenge. The roots need to be specific to the insurance plan providing the card, but of course there's no chance of them being on the card, and without a centralized infrastructure, there's no easy way to find out what they are. <br /><br />While in theory each application can make up its own GUIDs for each health plan they encounter, you then lose interoperability with anyone else. Insurance ids really meet the characteristics of "Common Public Identifiers", as described in V3 Core Principles, meaning they ought to be included in the HL7 OID registry, and compliant systems should use the roots found there.<br /><br />The fact that the identifiers often need to be concatenated to ensure uniqueness (and the specific concatenation rules can vary from insurer to insurer just makes things more complicated. Even if you're creating your own OIDs, you're going to run into a problem if you don't concatenate correctly because you'll end up with false matches.Lloyd McKenziehttps://www.blogger.com/profile/00932569469355993605noreply@blogger.comtag:blogger.com,1999:blog-733074358901582680.post-4884515296811967312012-10-31T19:09:10.252-04:002012-10-31T19:09:10.252-04:00Uhh, Llloyd, those are elision marks identifying e...Uhh, Llloyd, those are elision marks identifying extra gunge that I discarded for clarity. Of course they aren't but should be OIDs (or UUIDs which are also perfectly legal). You would bring up that mess...<br /><br />What I usually recommend is that folks use UUIDs for the root on identifiers, and be consistent with how they are used internally.<br /><br />Keith W. Boonehttps://www.blogger.com/profile/16883038460949909300noreply@blogger.comtag:blogger.com,1999:blog-733074358901582680.post-11630281475955409322012-10-31T17:35:13.356-04:002012-10-31T17:35:13.356-04:00The id attributes with root="_" aren'...The id attributes with root="_" aren't actually valid for Datatypes R1. The root must be an OID, and "_" isn't one. What *ought* to happen is that each ensurer has an OID, with child OIDs for the various card identifier components, though of course there's a challenge making systems aware of those and able to look them up. An additional challenge is that often the various id components aren't unique within the context of an insurer. For example, policy number might only be unique in the context of group number. To deal with this, it may be necessary to create concatenated identifiers to achieve global uniqueness.<br /><br />To get around these restrictions, you need to specify a null flavor - essentially declaring up front that the id isn't valid or useful computationally. (At least not the way the II datatype intem to be.) The ideal datatype would be UNC, but that's not available for CDA. So you'd need to use UNK or something similar.Lloyd McKenziehttps://www.blogger.com/profile/00932569469355993605noreply@blogger.com