You know that part where they ask for your insurance card.
Below are some samples of insurance cards.
There are identifiers for the policy, which is often labeled "Group Number". This represents the identifier for the policy covering the healthcare activity. Then there's an identifier for the policy holder, usually called the subscriber identifier. But that gets confusing because some plans also call that the policy-holder's member number.
Then there's the member id (or member number). That identifies the family member being covered, and is usually the subscriber-id followed by a sequence number. Some plans use -1 for the subscriber, -2 for the spouse, and then children as -3 to -n in birth order. Others alphabetize by first name (as mine did). That makes my eldest daughter -2, my wife -3, and my youngest daughter -4.
Following that, there could be one or more plan identifiers. These are the identifiers for the specific kind of insurance plan that you have. They represent a particular kind of insurance plan, and from what I can tell, are managed by state insurance regulators. It's not uncommon to have a separate plan covering your regular care (e.g., ambulatory), and a separate plan for hospitalization.
OK, got that? Now, what about the payer ID? There isn't one yet, but I expect after the regulations pass and every payer has an identifier, you'll find that there as well.
Some cards also double as Pharmacy Benefit Management cards. Those will have two additional numbers on them, called RxBIN and RxGRP, which are routing numbers used to identify how to communicate with the PBM (effectively identifiers for the PBM).
When we built CCD, we started from a coverage model developed by the HL7 Financial Management workgroup. That model appears below:
The Coverage Activity template represents the list of policies (or programs like CHIP, Medicaid, et cetera) that provides coverage to the patient. It contains one or more policy or program activities which describe one component of the coverage. These can be sequenced (really prioritized) by the sequenceNumber field in the act relationship.
The policy activity has an identifier. This is the "policy number" or "group number" associated with the policy or program covering the patient.
The plan act defines the policy and is where you'd put the plan identifier.
The covered party is the patient. The identifier associated with them is where you put the member id.
The responsible party is the "policy holder", and is where you would put the subscriber id.
Finally, the Payer is who actually makes the payment, and is where you'd put the PBM routing numbers, or payer ids when those become available.
The HITSP C83 specification goes into great detail on this section of the CCD, explaining where the content goes. At the end of this post, you can find a full example that has been pieced together from various examples in that document.
The C-CDA follows a similar pattern. You should be able to cross-walk the templates yourself using the template map in the appendix of C-CDA.
-- Keith
<act classCode='ACT' moodCode='DEF'>
<templateId root='2.16.840.1.113883.10.20.1.20'/>
<templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.17'/>
<id root=''/>
<code code='48768-6' displayName='Payment Sources'
codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/>
<statusCode code='completed'/>
<!-- Example 1, A health plan -->
<entryRelationship typeCode='COMP'>
<sequenceNumber value='1'/>
<act classCode='ACT' moodCode='EVN'>
<templateId root='2.16.840.1.113883.10.20.1.26'/>
<templateId root='2.16.840.1.113883.3.88.11.83.5'/>
<id root='2844AF96-37D5-42a8-9FE3-3995C110B4F8'
extension='GroupOrContract#'/>
<code code='IP' displayName='Individual Policy'
codeSystem='2.16.840.1.113883.6.255.1336'
codeSystemName='X12N-1336'/>
<statusCode code='completed'/>
<performer typeCode='PRF'>
<!-- This examples assume an RxBIN of 699999 and an RxPCN of PZZZZ -->
<assignedEntity classCode='ASSIGNED'>
<id root='2.16.840.1.113883.3.88.3.1' extension='699999'/>
<id root='2.16.840.1.113883.3.88.3.1.699999' extension='PZZZZ'/>
<addr>…</addr>
<telecom value='…'/>
<representedOrganization classCode='ORG'>
<name>…</name>
</representedOrganization>
</assignedEntity>
</performer>
<!-- Example 2, The patient is a dependent of the subscriber -->
<participant typeCode='COV'>
<time>
<low value='20070209'/>
</time>
<participantRole classCode='PAT'>
<id root='…' extension='MEMBERID#'/>
<code code='DEPEND' displayName='dependent'
codeSystem='2.16.840.1.113883.5.111' codeSystemName='RoleCode'/>
<playingEntity>
<name><given>Baby</given><family>Ross</family></name>
<sdtc:birthTime value='20070209'/>
</playingEntity>
</participant>
<participant typeCode='HLD'>
<participantRole classCode='IND'>
<id root='…' extension='SUBSCRIBERID#'/>
<playingEntity>
<name><given>Meg</given><family>Ellen</family></name>
<sdtc:birthTime value='19600127'/>
</playingEntity>
</participant>
<entryRelationship typeCode='REFR'>
<act classCode='ACT' moodCode='DEF'>
<id root='2844AF96-37D5-42a8-9FE3-3995C110B4FA' extension='PlanID'/>
<code code='HMO' displayName='health maintenance organization policy'
codeSystem='2.16.840.1.113883.5.4' codeSystemName='ActCode'/>
<text>Health Plan Name</text>
</act>
</entryRelationship>
</act>
</entryRelationship>
</act>
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.
ReplyDeleteTo 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.
Hello how about adding 2 Ids to the
Delete-act classCode='ACT' moodCode='EVN'-
Like this..
-id root='2844AF96-37D5-42a8-9FE3-3995C110B4F1'
extension='Group#'/-
-id root='2844AF96-37D5-42a8-9FE3-3995C110B4F2'
extension='Contract#'/-
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.
Note: I haven't tested/validated the idea
PS: I had to change some characters for the comment to be valid, but I hope you guys get the idea.
Do this instead according to Lloyd's message:
Delete-id nullFlavor='UNK' extension='Group#'/-
-id nullFlavor='UNK' extension='Contract#'/-
And you'll be all set.
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...
ReplyDeleteWhat I usually recommend is that folks use UUIDs for the root on identifiers, and be consistent with how they are used internally.
Hi Keith,
ReplyDeleteSorry. Too small a font on my end :>
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.
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.
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.
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.
ReplyDeleteThe 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.
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.
The standard has been updated since I left the scene. Aspects I've described may have changed. But a standard does indeed exist.
You can get the standard here: http://www.wedi.org/snip/public/articles/prot/index.cfm?pdfid=3593&ID=1009. It requires registration, but no payment as far as I can tell.
Delete