HL7AU - FHIR WG : Medicare Number

We need to document where the reference number is.

Is the format of the number:
NNNNNNNNNN (10 digits)

NNNN NNNNN N (10 digits)

NNNNNNNNNNN (11 digits)

NNNNNNNNNN-N (11 digits)

NNNN NNNNN N - N (11 digits)

or something else?

Does the information in section 7 "Medicare Card Number" of HB 234-2012 help:

"For the Medicare card number to be used as an identifier, all 11 digits are required, owing
to the fact that only the combination of all three data elements uniquely identifies a person.

This identifier is never recycled."

 The examples section would suggest that "NNNNNNNNNNN (11 digits)" is the format to use.

With the last digit being the patient's reference number? (the digit before the name at the bottom)

A practical observation. When Medicare Card is renewed once in 5 years, the 10th digit changes (e.g. from 1 to 2). Which means 1 person can have 2 or more numbers, only one being active at a moment in time. Does this make sense?

The details of using medicare card number is at http://meteor.aihw.gov.au/content/index.phtml/itemId/270694 

First 8 digits are card identifier. The 9th is checksum. The 10th is issue number. And the 11th is the individual reference number (between 1 and 9)

Patient's medicare card number changes over the time but only one is current. In the olden days, lots of clerical staff only collection the first 10 digits from patient. But, as the new FHIR guideline, it should force to be 11 digits. 

Yes, patient's can have multiple Medicare Card Identifiers, and some could be expired.

Yes, patients, particularly children, can have multiple current Medicare Card Identifiers if listed on separate parent Medicare Cards.

Sentinel values are encoded into otherwise invalid Medicare Card Identifiers, per AS 5017-2006. These are known to have been (and are) used in some hospital Patient Administration Systems:-

00000000000 - denotes eligible, but unregistered.

00000000009 - denotes ineligible for Medicare.

88888888888 - denotes unknown Medicare Card Identifier.

99999999999 - denotes registered, but card unavailable.

I have just written to John Wong at Human Services (Medicare) asking for permission to create the required namespace 'http://ns.electronichealth.net.au/id/hi/mc' or suggest and alternative. Will keep you informed on how it goes. 

20160914: We have had our (The Agency) exec contact Karen Hebditch at human services asking for them to work with us on resolving an agreed url for this purpose. Yet that was on the 11/08/2016 and we have not had any movement since then. I will write as a follow-up and try and get some forward action

We should also consider the temporary card numbers (hospitals and maternity)

(and how international cases are covered - this could be considered out of scope also)

These 2 cases could be considered as a separate profile.

I don't understand why Human Services 'approval' is needed for creating this namespace. It is simply an identifier used within a FHIR resource to scope Medicare Numbers. The Agency owns the domain name electronichealth.net.au and so is the most authoritative organisation to name URLs within that, and to establish any documentation at the URL's site. See http://ns.electronichealth.net.au/id and follow the links. Note also the version numbers. I doubt Human Services were approached for 'approval' to establish e.g. http://ns.electronichealth.net.au/id/hi/ihi/1.0

May I ask who are the owner for FHIR profile which we are working on? If HL7AU owns the FHIR Profile, why not create OIDs or hl7.org.au namespace for those identifiers?

1. DHS own the Medicare Numbers, so the URL we use SHOULD be one of theirs.  (The HI URLs are different because NEHTA, now the Agency, is custodian of the identifiers; DHS are just the operators.)  However, in the interests of time, if Medicare cannot – or cannot quickly – point us to a URL,then an Agency URL is a sub-optimal fallback.  Nonetheless, as a courtesy, the Agency should still get "permission" from them to do this.  I suppose if that's not forthcoming, but DHS are slow with the URL, the Agency can act precipitously, but it would be better to avoid that!
2. The owner of the profile and the owner of the identifier have nothing to do with each other.  Profilers cannot create, willy-nilly, URLs for identifiers however they like; interoperability will break down very quickly if people do that.

Hi Stephen,

Yes, you are right. The owner of profile and identifier are different. But, the problem is that HL7 cannot guarantee all of the identifier owners would like to create a namespace to be used by HL7 in time. That's why HL7 table 0203 has been used for that purpose. And we would not need to ask Department of Foreign Affairs and Trade to give us a namespace for passport number.

IMHO, by adding the Agency's namespace wouldn't provide better interoperability than HL7AU's own namespace. For example,  http://ns.electronichealth.net.au/id/pcehr/caei/1.0 has been used to represent MyHealth Record care agency employee's identifier number which contains outdated PCEHR prefix. And, distinguished name has both http://ns.electronichealth.net.au/id/hi/distinguishedname/1.0 and http://ns.medicareaustralia.gov.au/id/hi/distinguishedname/1.0 namespaces which do create more complexity. 

J

1. I think we SHOULD ask the Department of Foreign Affairs and Trade to give us a namespace for passport number, and, as in this circumstance, only create our own if they cannot do so in a timely manner.
2. I am not promoting an Agency namespace over an HL7 Australia namespace; I am promoting a single namespace to be used by all, be that an Agency one or an HL7 Australia one.
3. What I was saying is that there are many people who want to create profiles for all sorts of things, including HL7 Australia, and none of them should be free to just create a namespace for an identifier in a profile because they need one.  It needs to be managed, and, preferably in a distributed manner. Given that, the only way to get the namespace is from the owner of the identifier.  However, as already agreed between us, timeliness is crucial, so there will pragmatically need to be a central authority for issuing namespaces as well.  The Agency has fulfilled that role to date, but there is no reason why HL7 Australia couldn't take it over.  Indeed, HL7 Australia has many reasons why it is eminently qualified to do so; I was simply saying that being the owner of the profile is not one of them.

The real advantage of using a namespace that is managed by the owner of the identities is that that namespace then becomes common across multiple systems/standards. i.e. in the example of passport numbers;

• They may be stored on a patients demographic record and sent using FHIR
• A travel booking may be sent using a separate messaging standard.

If the namespace if assigned by hl7 etc then either system that use multiple standards will need to maintain a mapping between the hl7 namespace and any other namespaces used for passport, or the hl7 namespace is used in other standards. If the namespace is assigned by the identity owner then this namespace can be common across multiple standards.

That is my 2 cents anyway.

The other benefit is that it gets them involved and aware of what we are doing, and then hopefully next time the got to ask providers/vendors for data they know what should already be there and make it easier for everyone. (which will lower the overall cost to everyone as a result)

I think that any valid medicare card number (including temporary numbers) should be included in this spec. If a patient does not have a medicare card number (permanent or temporary) then this would be covered with other identity types.

I do question if we need to spell out recording if a patient does not have a medicare card. This would prevent multiple people asking for a medicare card if a client has already indicated they do not have one.

1. Stephen Royce neither NEHTA nor The Agency has been "custodian" of the national healthcare identifiers (IHI, HPI-I, HPI-O). NEHTA isn't mentioned in the Healthcare Identifiers Act. The Service Operator is the CEO of Medicare Australia, who also assigns the identifiers and presumably therefore the "custodian". Additionally, APHRA ( a Registration Authority under the Act ) may assign HPI-Is to healthcare providers who are already registered by them.

2. Stephen Royce  It is often not easy to identify the "owner" of either a profile, nor of an identifier. I agree they are not the same concepts. It would be nice to have some notional agreement amongst stakeholders who contribute to a profile, a bit like was done with development of the Standards Australia standards for healthcare information. Interoperability depends on acceptance and adherence, so it makes sense that they contribute to development in some fashion, or at least be offered input on matters most relevant.

3. The namespace "ns.electronichealth.net.au" was not arrived at by NEHTA willy-nilly. It was well thought out, and carries no organisation or technology embedded in its name. Organisations come and go. Organisations change their names. Completing the namespace URL by using the prefix "http://" confers some advantages, particularly if curated well by a national organisation tasked with overarching responsibility for digital healthcare in Australia. Subsetting the namespace URL with succinct path suffixes that dont' include organisation names is also sensible, although not always possible. Creating documentation returned by an HTTP GET of the URLs under http://ns.electronichealth.net.au has been a useful facility provided by NEHTA.

4. Isn't the FHIR system element actually establishing a namespace for the identifier? It is not about which organisation is authoritative ( i.e. governs ) the identifier. It is not about who assigns the identifier. It is about scoping the identifier. The combination of system and value should a) make the identifier unique within the resource, b) enable participating systems to be programmed to "process" the identifier reliably.

5. Dept of Human Services has already knowingly allocated identifiers scoped by "http://ns.electronichealth.net.au/id/vendorid/1.0".

6. Allocating an identifier such as "http://ns.electronichealth.net.au/id/hi/mc" does not preclude others from using that in the future for other information uses in other contexts.

7. Having the identifier "owning" organisations, such as Dept. of Human Services create the namespace URL would not necessarly make it any more likely that the namespace URL would be the only one used into the future, independent of the context.

8. Having the identifier "owning" organisations, such as Dept. of Human Services create the namespace URL would not necessarly make it any less likely that there could be a proliferation of resources with different system URLs for the same identifier type.

9. HL7 has already created a range of namespaces for Australian Medicare Numbers. HL7 v2 has "AUSHIC"; NEHTA HL7 CDA has 4 separate OIDs created by Grahame Grieve  ( see http://www.hl7.org/Oid/index.cfm?action=search&assignment_status=&search_comp_OID=1.2.36.1.5001.1.0.7 )

10. Brian Postlethwaite, I agree it might be nice to get some buy-in by each relevant, responsible/"owner" agency, but I'm skeptical that that would occur in practice. It is likely that some agencies will a) not understand the requirement, b) assign the task to the wrong person/section, c) seek advice from their legal department who may well then seek legal advice from a third party, d) produce a namespace URL that is inadequate to meet the requirements, e) fail to manage the URL as well as (dare I say it) The Agency.

11. I'm not sure that the requirements have been sufficiently bedded down. e.g. Should there be separate URLs for the different length Medicare Numbers as Grahame Grieve did with the CDA OIDs? Are there requirements for versions that need to be embeded in the URL?

So you'll get no argument from me that many organisations will not respond in a timely manner to requests for URLs for their identifiers; in fact, I suspect many will have no capacity to handle such requests anyway.  Nonetheless, we should still try.  Furthermore, I understand the provenance and advantages that come with the http://ns.electronichealth.net.au namespace and I'm certainly not arguing against using it.  I also understand that the Agency has more than sufficient capacity for managing that namespace and I know we are gearing up to be able to do that better still, so I certainly would not suggest that the Agency shouldn't be doing it; however, HL7 Australia is still a viable alternative and may be politically more palatable.  And regardless of where the URLs are acquired, we still need someone to manage a central register to avoid the proliferation of URLs of which you speak.  Again the Agency are gearing up to be able to provide such a service, but HL7 Australia may be preferable to some, I don't know.  The Agency is certainly happy to take on these roles should the community decide that's what they want, but we're no longer in the business of mandating such!

Assuming we're going with an http://ns.electronichealth.net.au namespace, can I suggest that we should be dropping the "hi" from the Medicare Number URL since these numbers are completely separate from the HI numbers service?  I also think we should use "mcn" not "mc" since we may want to use "mc" to refer to Medicare as a whole. I'd prefer http://ns.electronichealth.net.au/id/mcn or http://ns.electronichealth.net.au/id/dhs/mcn.

I like  http://ns.electronichealth.net.au/id/mcn  

Andy Bond, Stephen Royce, Angus Millar from the Agency and John Wong, Janette Mason, Jae Yeo from Human Services all met to discuss the Medicare Number namespace, or rather namespacing for all Human Service's identifiers.

We focused the discussion around resolving the question of whether we can use 'http://ns.electronichealth.net.au ' as the domain name for these URI's. We did not delve into the variety of namespaces required but loosely agreed that we should follow the OIDs that have already been assigned for each identifier and their parts, the idea being that we assign a URI for each OID. This discussion still needs to continue and it was suggested that this done here and in the Wednesday meetings.

The meetings core focus was to get a decision that we can use 'http://ns.electronichealth.net.au ' as the domain name in the URI's. John Wong from Human Services has kindly agreed to seek approval for this decision within Human Services. I will follow up with John in a week to see how he has gone.

Thank you for the update Angus — sounds like progress is being made. I support the idea that URI counterparts for the existing OIDs be provided.

Did the DHS attendees comment on whether using the Medicare card as a Patient identifier is acceptable (as opposed to it being an Entitlement identifier) ?

Patient identifier vs Entitlement identifier wasn't discussed. My view is that this work is not about saying what an identifier is or is not to be used for. It's only to formalise how to send the identifier, not what you do with it once you have it.      

Understand. To your view, on formalising how to "send the identifier", I think the system URI is a key part of that. However, another part is how you associate that identifier with a FHIR Patient resource which is where I was going with my question. In the past, there has been considerable opposition to using the Medicare card number as a Patient identifier (which may explain why all existing NEHTA/Agency CDA Implementation Guides model it as an entitlement). It would be good to resolve this once and for all now that DHS are part of the process.

Just for clarification: the reason NEHTA did that is because the relevant act of parliament expressly forbids using the Medicare number as an identifier.  (Well, that's our understanding anyway.)  This is actually one of the main drivers behind the requirement for the national HI service.  The oft stated reason of the lack of uniqueness of the Medicare number is actually not really a problem.  (Or, more correctly, a problem with viable work-around.)  So, unless someone can clearly show that there is no legal impediment to using the Medicare number as an identifier, this will continue to be the Agency's position.

I would like to think the FHIR 80% rule would prevent that sort of over analysing.    

The only identifier which stated by DHS is IHI for both Australian residents and overseas visitors. For legal reason, there is no unique personal identifier to be used in public. And Medicare number does not have any privilege than other types of IDs issued by Australian government body to identify a patient.

So we seem to have in principle support from Department of Human Services (DHS) that they will support a namespace for medicare number starting with 'ns.electronichealth.net.au'. In their investigations they actually found another namespace in use in some web services which was 'https://ns.electronichealth.net.au/hi/xsd/consumercore/ConsumerCoreElement/3.0' yet this is a namespace for the definition of an XSD structured named 'ConsumerCoreElement' which looks like this:

The definition for ConsumerCoreElement is:

<xsd:simpleType name=”MedicareCardNumberType”>

  <xsd:restriction base=”xsd:token”>

    <xsd:minLength value=”10” />

    <xsd:maxLength value=”10” />

  </xsd:restriction>

</xsd:simpleType>

  <xsd:simpleType name=”MedicareIRNType”>

    <xsd:restriction base=”xsd:integer”>

    <xsd:minInclusive value=”1” />

    <xsd:maxInclusive value=”9” />

  </xsd:restriction>

</xsd:simpleType>

There seems to be the consensus that this is not fit for our purpose and could not be reused. I will, however, reiterate DHS's concerns that any new namespace we create for Medicare Number here is not to change the current web services (i.e HI Service). I think this is well understood by all here.

So progressing to actually create the new namespaces / URI. It has been proposed that we mirror the OIDs that have already been assigned to the Medicare Number and it's elements.

They are:

Where the mapping to a Medicare Care is as follows:   

And finally the current suggestion for FHIR URI / namespaces for each are:

How do people feel about these?

Hi Angus,

Thanks for the great work. Not sure "individual" for imcn is necessary as people normally call that medicare card number instead of individual medicare card number. Also, 'medicare card number' (N11) is used in most of the data dictionaries including AIHW metadata.

J

These are the names already used in the HL7 OID register so they can't be changed; but, even if we could, technically the Medicare Card Number is the 10-digit number (without the IRN) so it would not be appropriate to use that name as the formal name of the 11-digit number no matter what the common usage is.  It is unfortunate, though, that METeOR uses the term for the 11-digit number.

Hi Angus

Thanks for the update. I have the following feedback items/suggestions:

1. It would be good to have part of the URL path recognise that these relate to the Department of Human Services (DHS) (as the 5001 does in the OID representation) and also Medicare as the relevant agency. Perhaps "dhs/medicare/" preceding "id/" .
   
   
2. In the issue number URL, "issue-nr" introduces inconsistent use of abbreviations. Why not just make it "in" ?

Did DHS say anything about use of these as a Patient identifier ?

1. If you look above, I suggested using http://ns.electronichealth.net.au/id/dhs/….  I prefer this, but others – the lazy ones among us?  – prefer the shorter version. I think having "id" before "dhs" rather than after is important because it's not DHS who'll be managing these.  That means we can standard on the ID format as http://ns.electronichealth.net.au/id/<Owner>/<Type>.
2. The abbreviations are down to me.  I felt that "in" is just too ambiguous.  I realise this is very subjective though.

My suggestions:

http://ns.electronichealth.net.au/id/mc11

http://ns.electronichealth.net.au/id/mc10

http://ns.electronichealth.net.au/id/mc-issue

http://ns.electronichealth.net.au/id/mc-irn

A problem with namespace ids incorporating department names is that the latter are highly ephemeral. Probability of department name change with change of government is high.

One of the principles we agreed with DHS is that the URIs would reflect the OID structure.  This means that the 3 shorter numbers need to be "children" of the 11-digit number URI.

Fair point.

How unfortunate.

Most people think of the 11 digits as the 'Medicare Number'. What we are trying to distinguish between is the 'medicare-number-individual' and 'medicare-number-card'. The names in the OID registry would seem to be of peripheral relevance - surely this just a mapping thing. Have we asked the OID registry for permission to use their symbolic names for a secondary purpose?

I would opt for going with the language that people use rather than something something in a document designed by a committee of non-terminologists.

More background information:

1. The OIDs belong to us (the Australian Digital Health Agency) as does the http://ns/electronichealth.net.au namespace; there's no need to ask for permission.
2. The symbolic names of the OIDs are, from a terminological perspective, the fully specified name, not the peferred term (exactly as they should be).
3. The URIs do not need to perfectly reflect the OIDs' symbolic names, but there needs to be a clear distinction between the "name" of the 11-digit number and the "name" of the 10-digit number. (By "name" I mean the portion of the URI used to describe the concept, e.g. from the original suggestion, "imcn" for the Medicare number – individual and "mcn" for the Medicare number – card).

From what I can understand is:

[Medicare Number] = [Medicare Card Number] + [Individual Reference Number]

[Medicare Card Number] = [Card Number] + [Issue Number]

On the other hand, there are three types of medicare card:

• Green: Australian Resident Card
• Yellow: Reciprocal Health Care Card
• Blue: Interim Medicare Card

Are we going to include the card type in the namespace?

We could.  Are there any requirements to do so?  Are the structures of the numbers any different across the different card types?

We've just had a meeting here in which this was discussed further.  We would now like to propose these URIs:

These are somewhat long-winded, but we felt it was important that:

1. it was clear even to people coming to this with no prior background that we're talking about medicare numbers here ("mcn" and the like was felt to still be a little too cryptic); and
2. the URIs contain the number of digits where that's relevant to help stop people doing things like sending a (10-digit) Medicare Card Number using the (11-digit) Medicare Number URI.

It's really small user case (possibly in health insurance industry) and most of people may never see those cards.

All those three types have the same format and cannot be distinguished by card number. 

Will this naming convention impact the other patient identifiers within current FHIR Profile draft?

Such as?

Such as 

http://ns.electronichealth.net.au/id/hi/crn

change to 

http://ns.electronichealth.net.au/id/centrelink-customer-reference-number

Not if they're already defined at http://ns.electronichealth.net.au; otherwise, yes; maybe.  Remember, though, that these are just suggestions.  If folks don't like it, then we can agree on something else.  We could, for instance, shorten "medicare-number" to "medicare-nr" without much, if any, loss of understanding. All suggestions and thoughts are welcome although we will, of course, have to stop talking and start doing at some point.

Thanks for the reply. Before we can settle down the details, is there any naming convention standard has been defined for the Agency's namespace?

I'm happy to use whatever namespace been defined in the FHIR Profile but hope that can be consistent if they come from same domain and commonly understandable in the Australian health care setting.

J

Stephen, I'm not as convinced as you that DHS are strict on following the OIDs structure, but rather that we need to cater for each. The latest suggestions here I like except for the duplication seen in 'http://ns.electronichealth.net.au/id/medicare-number-11/medicare-number-10'. Personally, I would like to flatten further and be more explicit on the digits. 

Here is my go, again:

Yeah; so in the absence of a proper ontology where we could say that http://ns.electronichealth.net.au/id/medicare-number-10digits is a sub-concept of http://ns.electronichealth.net.au/id/medicare-number-11digits, we lose the relationship if you flatten them out.  I do understand that relying on the URI to convey the relationship is poor (as it is with OIDs), but it does help.  Otherwise, it could be construed that the 10-digit number is a different type of medicare number to the 11-digit one instead of a component part of it.  These subtleties are, admittedly, quite esoteric, and perhaps no-one but me cares.

I would advise against URIs which do not reference the fact that this refers to the Medicare CARD somehow. Do note that these are not the only identifiers that Medicare issues. There are also prescriber, provider, and dispensing organisation identifiers.

Technically, the full 11-digit number is not a card number.  The card number is the 10-digit number only.

It's a good point, maybe 'id/medicare-card-number-11digits' ?

Except that it is not the number of the card. Each 11-digit number is a Medicare Number of the nth person on the card

From my experience it is quite common to use the acroynym 'MC' to mean 'Medicare' even though that's wrong - Medicare is on word. None the less that's what people do.

So wouldn't it make sense to use

MC - for Medicare Number

MCC - for Medicare Card Number

Even the above suggestion can be simplified without ambiguity

Hum, well, yes, this does seem to be a terminology discussion. So I guess I should point out that 10th isn't in the same namespace as # of digits.

There's these things called cardinal, ordinal and nominal. My mother the maths teacher is turning over in her grave as I read this.

Let's see, Peter Brock's car was number '05'. Is that cardinal, nominal or ordinal?

May be 'subset of digit's, with (1-11), (1-10), (10), (11).

Or 'function of number', with 'this', int(this/10), int(mod(this, 100)/10) and mod(this, 10)

Or 'substring of number' with this[0:11], this[0:10], this[9:10] and this[10:11]

Or perhaps we just use all 11 digits and say that anything that isn't 11 digits is wrong and needs to be fixed. After all, who cares about the little bits on their own, taken out of context.

Who cares that, according to Medicare, I'm a '1' and my wife's a '2'.

Or perhaps we just call it a 'hash structure' with alternate hash elements, as in 3134647552['1'] === 3134647552['RUSSELL A MCDONELL']

After all, 10 digits isn't enough without either the IRN or the name. So why isn't there a URI for medicare-number/name to match medicare-number/irn

I'm happy to talk maths and set theory if you really want, but I'm pretty sure we don't need to get that complicated.  We have a single OID, and now URI, for the medicare number which is the full 11-digit number that is "unique" to an individual.  The other items are various significant components of that number and so are sub-ordinate OIDs and now URIs, so they can quite happily share the namespace.