Created by Brian Postlethwaite, last modified on 20 Jul, 2016

Overview

  • The value must be 16 digits with a prefix of "800360", and validate with a Luhn check (no spaces or separators)
  • use existing system url; no-trailing slash "http://ns.electronichealth.net.au/id/hi/ihi/1.0"
  • type: optional display elements
  • use, period are context of use dependent, optional
  • assigner not required (it is implied/fixed for IHI)

 

Example:

<Patient>
    ...
    <identifier>
        <type> 
            <coding> 
                <system value="http://hl7.org/fhir/v2/0203"/>
                <code value="NI"/>
                <display value="National unique individual identifier"/>
            </coding>
            <text value="IHI"/> 
        </type>
        <system value="http://ns.electronichealth.net.au/id/hi/ihi/1.0"/> <!-- Required -->
        <value value="8003608166690503"/> <!-- Required -->
    </identifier>
    ...
</patient>

Including IHI Status information:

The above general definition doesn't include support for the Identifier status, nor verification information, which is not always required.

This guidance is not intended to tell you under what conditions you need to use this information, just how it should be represented if you do need it, and some context information that may be relevant.

Propose that we use the period to indicate that date that the identifier was checked, and for previous values (provisional/unverified) of the identifier be end dated, rather than removed.

Partial example of an Identifier including the status information: (extending the above format, not replacing it)

<identifier>
    <extension url="http://ns.electronichealth.net.au/id/hi/ihi/1.0/StructureDefinition/ihi-status">
        <valueCoding>
            <system value="http://ns.electronichealth.net.au/id/hi/ihi/1.0/CodeSystem/ihi-status" />
            <code value="Active"/> <!-- Could be one of Active, Deceased, Retired, Expired or Resolved -->
        </valueCoding>
    </extension>
    <extension url="http://ns.electronichealth.net.au/id/hi/ihi/1.0/StructureDefinition/ihi-record-status">
        <valueCoding>
            <system value="http://ns.electronichealth.net.au/id/hi/ihi/1.0/CodeSystem/ihi-record-status"/>
            <code value="Verified"/> <!-- Could be one of Verified, Unverified or Provisional -->
        </valueCoding>
    </extension>
    <type>
        ...
    </type>
    <system value="http://ns.electronichealth.net.au/id/hi/ihi/1.0" />
    <value value="8003608166690503"/>
    <period>
        <start value="2016-07-08T09:43:12+11"/> <!-- the date/time that this identifier was verified and can be used -->
	<!-- When recording an expired or retired identifier, the end date is recorded here. -->
    </period>
</identifier>  

The draft versions of the 2 code systems used above can be found here: codesystem/ihi-status, codesystem/ihi-record-status.

Where the IHI has expired it should look like this, it may also include the date the expiration status was detected in the identifiers period.end date/time.

This approach will therefore have a new version of the Patient record each time the identifier is verified, which as a side effect provides the full detail of what information was used that was checked and had the verification outcome in the Auditing.

Could a custom operation be defined on the Patient resource to refresh the status?

Additional comments

AS4846-2014 Reference

  • 3.4.2 Identifier Desgination - IHI format 800360 prefix; length 16 digits; Luhn check; Nationally Unique
  • 3.4.3 Identifier Issuer - is implicit for IHI (need an explicit fixed value for this?)
  • 3.4.4 Group Identifier Flag - implicit none; individual
  • 3.5.2 ID Status Start Date - mapped to validity check date (last check)
  • 3.5.3 ID Status End Date - optional not explicitly stated
  • 3.5.4 Identifier Status Code - A = Active   R = Inactive (Deceased, Retired, Expired, Resolved)
  • 3.5.5 Identifier Replaced By - out of scope
  • 3.5.6 Duplicate Confirmed By - out of scope
  • 3.7,2 Identifier Usage - implicit 110 - Individual Healthcare Identifier (IHI)
  • 3.7.3 Identifier Usage Start Date -  mapped to validity check date (last check)
  • 3.7.4 Identifier Usage End Date

 

Attachments:

20160814 DRAFT IHI Status CodeSystems.zip (application/zip)
20160719 IHI Status CodeSystems.zip (application/zip)
20160719_V2 IHI Status CodeSystems.zip (application/zip)
ARB_BriefingPaper-FHIR_Foundations_Canonical_URIs_and_Structure_Definitions.pdf (application/pdf)

Comments:

ihi-number-status + ihi-record-status can we make it more FHIRy by lower casing the codes? 

  • active,deceased, retired, expired, resolved
  • verified, unverified, provisional 
Posted by b_esler at 08 Jul, 2016 19:00

I'd rather just reference their actual values than try and create another one that we need to map.

Hence defer to "The Australian Digital Healthcare Agency" to define and expose the ValueSet (and we can just reference it)
Posted by brian_pos at 08 Jul, 2016 20:57

agreed
Posted by b_esler at 08 Jul, 2016 23:40

I have created two draft CodeSystems with implicit ValueSets for the 'IHI Status' and 'IHI Record Status'. Still working on what the CodeSystem & ValueSet URL should be. Your suggested URL's above are what I have at present, still want to confirm that these are what we will go with. 

I also want to get these published in the national ONTO Server which is an untrodden path to navigate, would be the first ValueSets aside from SNOMED-CT content.

The query above "need to check if the Time component is actually required". I would say yes due to our conformance requirments, see below:

------------------------------------------------------------------------------------------

Use of Healthcare Identifers in Health Software Systems 

Software Conformance Requirments V3.1 (Link to doc)

REQ: 005820 

Recording of IHI details upon IHI assignment and update   

When assigning a new IHI or updating IHI details in a patient record,
the software shall store:

  • the IHI number;
  • the IHI number status (Active/Deceased/Retired/Expired/Resolved);
  • the date and time of the assignment/update (the assignment time shall be stored in hours and minutes unless the system is capable of more precision); and
  • the IHI record status (Verified/Unverified/Provisional).

Priority: Mandatory
Applicable to: UC.010, UC.011, UC.015, UC.025, UC.035
Additional Notes:
Knowledge of the IHI number status, IHI record status, and date of
assignment/update is used in the ongoing maintenance of an IHI in a
patient record. The software shall retain previously assigned IHIs,
including their number status and record status, in the patient
records for historical purposes (see requirement 5847).

------------------------------------------------------------------------------------------

 
Posted by angusmillar at 12 Jul, 2016 12:50

Hum, when I fetch something from My Health Record, using the new FHIR APIs, I get stuff like

<medicationReference>
    <reference value="#1.2.36.1.2001.1005.27.1.2"/>
</medicationReference>
<patient>
    <reference value="Patient/8003608333429777"/>
</patient>

Clearly the bit after "Patient" is the patient's IHI number.

Does this mean that when I store a MedicationDispense resource I should use the Medicare services to check that IHI?

And should we define an extension that can be applied to <patient> that allows that information to be stored with the reference?
Posted by russell.mcdonell at 14 Jul, 2016 14:01

20160719_V2 IHI Status CodeSystems.zip

Warning, a previous zip file was uploaded named '20160814 DRAFT IHI Status CodeSystems'. That zip file was incorrectly date stamped as 14/08/2016 and the CodeSystem resource files within also had errors. The zip file named '20160719 IHI Status CodeSystems' directly replaced the incorrect file.  Please delete any copies of the file named 20160814 DRAFT IHI Status CodeSystems.

I have discussed this proposal here at ADHA and have some feedback.

IHI Number Status

We believe this should be called 'IHI Status' to keep in line with the name used in the HI Service. Allows for easy traceability back to the technical documentation for the HI Service where this set originates from. I have created a CodeSystem resource for this and the ValueSet would be an implicit ValueSet off the CodeSystem. The CodeSystem and implicit ValueSet 'urls' we suggest for this set are below. I will also attach here a zip file containing both this and the other CodeSystem 'IHI Record Status'. These are still both draft as I want some others here to eyeball them and need to work out the correct value for the 'copyright' property on each. Would love any feedback from other here if you have any.  I'm also trying to work out where these FHIR resources would live going forward, any suggestions? 

CodeSystem

http://ns.electronichealth.net.au/id/hi/ihi/1.0/CodeSystem/ihi-status

ValueSet (Implicit)

http://ns.electronichealth.net.au/id/hi/ihi/1.0/ValueSet/ihi-status

 

IHI Record Status

Name here is fine 'IHI Record Status', it matches the HI technical documentation. I have created a CodeSystem resource for this and the ValueSet would again be an implicit ValueSet off the CodeSystem. The 'urls' we suggest for this set are below. You will also find this CodeSystem in the same attached zip file, once again in draft. 

CodeSystem

http://ns.electronichealth.net.au/id/hi/ihi/1.0/CodeSystem/ihi-record-status

ValueSet (Implicit)

http://ns.electronichealth.net.au/id/hi/ihi/1.0/ValueSet/ihi-record-status


Other Comments

Here are some other points raised in our discussion at ADHA with myself, Andy Bond and  Stephen Royce.

Use of a Period Datatype for the date that this identifier was verified

We were questioning why this is a Period and not a single DateTime? Questions were around what the end date would be set to while also noting that the Identifier datatype already has a 'period' property described as "Time period when id is/was valid for use" . So this extra Period element relates directly to the statuses and is currently described above as "Propose that we use the period to indicate that date that the identifier was checked, and for previous incarnations of the identifier be end dated, rather than removed.". What is meant by "previous incarnations of the identifier", why can't this be expressed by the core 'period' property on the Identifier element? 

We felt that a single DateTime should be given to the statutes that only indicates the Date & Time that the identifier / Statues were checked. Happy to hear others views.

Comment about Use of Statuses

We felt that the definition should also have some commentary indicating that systems receiving these elements still need to compile will all conformance requirements as stated in Use of HIs in Health Software Systems - Conformance Requirements. The key concern was that there are rules around receiving systems, across organisational boundaries, needing to revalidate the IHI on receiving it and storing it. Point being, just because you are told that the IHI status was obtained 1min ago does not exclude you from the requirement to revalidated it if it was received from an external organisation. We are worried that the presence of these new elements can misguide implementers in regard to their obligations around IHI use, see requirements references below.

Req:023942 Validation when incoming information matches a local patient record

Req:023943 Validation when incoming demographic data matches a local patient record and the local IHI is absent

I can get some text together in this regard.      

 

Moving forward

  • Me to finalise the two CodeSystem resources with others feedback
  • I can publish the namespace urls when required
  • Me to get text for the last point above if others agree
  • Do we use Period of DateTime for statues -(no we don't)

Comments from anyone welcome.

 
Posted by angusmillar at 14 Jul, 2016 14:03

That is a co-incidence (of sorts) on the ID number.

From my understanding they are using the IHI as the FHIR ID (as separate to the Identifier, which should be in the format we've been discussing above).

(It also means that they can't handle replacing the IHI when an interim one is generated)
Posted by brian_pos at 14 Jul, 2016 14:10

Do we need to check HPI-I's and HPI-O's as well when we save them?
Posted by russell.mcdonell at 14 Jul, 2016 14:11

Wasn't proposing having another period on the identifier, just use the existing one.

The end date would be populated if retaining the provisional/unverified IHI that was allocated before it is verified at a later point.

(I'm not 100% familiar with this area)

And also for ones that have the status of expired or retired.

On the Conformance Requirements, yes, this is what I was trying to get comment on also, and ensure that we had things covered.

The issue that will arise is identifying when the transition happens... (when the apps are separate but accessing the central data within the org)
Posted by brian_pos at 14 Jul, 2016 14:41

Patient/IHI wasn't a 'co-incidence' - it was a deliberate design decision; one which creates this conundrum for me. Do the rules around storing the IHI apply when you are storing the IHI as an accidental side effect of a design decision? It is still the IHI and it is still clearly the IHI. And you would want to preserve it for data linkage reasons. We know Patient/8003608333429777 is not the same person as Patient/8003608333429666 if, and only if, we assume that the id is the IHI. Otherwise we have to fetch both and look at the identifiers and compare the IHI values. Which would be clearly pointless if we assume id === IHI (unless some person has two IHI's, but of course that could never happen!).
Posted by russell.mcdonell at 14 Jul, 2016 18:26

Russell, are you storing things without the user's permission and consent? if you are, why? if you aren't, then it's not your decision, it's their decision, and they are authorised to use their own IHI as they see fit (unless you send their data to yourself for debugging...)

As for the choice of the MyHR portal to use IHI as the resource identifier: that should be understood as reflecting real world system design constraints, and not as a good idea for other systems to follow (they'll have to live with their own design constraints... that'll be enough with adopting anyone else's)
Posted by grahame_grieve at 15 Jul, 2016 13:52

According to Accenture, storing is the problem - even with the patient's consent. It is the organization doing the storing that has to comply with the legislation, which doesn't take into consideration 'acting on behalf of'.

It would be nice if I could invoke the Nuremberg defence - 'I was just doing what the patient told me to do. If that's a crime against humanity, then go shoot the patient', but alas ...

I guess I've spent my life railing against solutions where the design depends upon some accidental side-effect. They always come back to bite you in the bum.
Posted by russell.mcdonell at 16 Jul, 2016 10:20

where are you storing it? If it's not on the patient's computer, but on somewhere else, then, sure, you're storing it. 
Posted by grahame_grieve at 17 Jul, 2016 19:19

My bad thought you were suggesting a new Period for the status. I can see now that I misunderstood, this is just the core FHIR Identifier datatype's period.

As for end dating the IHI using this period, I can't see how we can advise on this at all. HI service does not provide an end date so any end date you presume from the statuses would only be formed from the date you requested the statutes, not the date the status was set in the HI Service. So the end date you presume would be different from system to system.

I think end date might have a use case within certain organisational boundaries but at this national level, we can't advise what that use case is.  
Posted by angusmillar at 18 Jul, 2016 13:36

Thanks for that clarification on the end date. Will update the notes.
Posted by brian_pos at 18 Jul, 2016 13:40

I have raised this with them previously. Patient/8003608333429777 implies the IHI is being used as the logical id of the patient resource when it should be the business Identifier. This is then contradicted in their sample API calls where the IHI is used as a business identifier? e.g. https://api.ehealthvendortest.health.gov.au/fhir/v1.0.0/MedicationOrder?patient.identifier=8003608000095968&date=ge2014-02-21&date=le2016-04-23
Posted by paul.barry at 21 Jul, 2016 13:17

The implication doesn't say that the identifier isn't in the identifiers collection also (and it should be, in the format we've documented here)

So the query is still valid, and uses the FHIR search parameter chaining.

However I wouldn't like to use that on other systems incase they have an identifier that co-incidentally looks like that, and they haven't documented the inclusion of the namespace for the identifier, but if the namespace was included, this query work equally well there or on my internal system.

 
Posted by brian_pos at 21 Jul, 2016 13:55

(wink) how about they hash the IHI for resource id - then it wouldn't look like one.... 
Posted by b_esler at 21 Jul, 2016 14:14

Internally we are not storing the IHI for 'privacy reasons'. I have already suggested

  1. Throw away '800360' and the last digit [ the checksum ]
  2. Apply ROT5 to the remaining characters (0123456789 -> 5678901234)

That would be 'nationally unique' without being the IHI (wink)

 
Posted by russell.mcdonell at 21 Jul, 2016 17:43

Yep - storing on the patient's property is fine. We can create a mobile app which download the whole a patient's My Health Record (CDA documents and all) and then stores it on their mobile phone or tablet. Be we can't say "Let us store that for you". So you might arrive at ED with your full medical record on your phone, but if the battery's dead, then so are you.
Posted by russell.mcdonell at 21 Jul, 2016 19:04

Copyright statements for the CodeSystems and ValueSets for the IHI-Status & IHI-Record_Status have been resolved, they are 'Commonwealth of Australia'. The two CodeSystems can be found here:http://terminology.hl7.org.au/open/CodeSystem/ihi-record-status and here: http://terminology.hl7.org.au/open/CodeSystem/ihi-status
Posted by angusmillar at 02 Aug, 2016 14:50

Great stuff Angus.
Posted by brian_pos at 02 Aug, 2016 14:52

I have received some great feedback on the proposed CodeSystem resources  from Reuben Daniels. In response, the following changes have been made and uploaded to the server.

  • CodeSystem.versionNeeded was set to True, have changed it to 'False', server updated
  • CodeSystem.version was '201408' yet the NCTS profile wants a format of YYYYMMDD so have updated it to 20140801

The points below are suggested changes for discussion which have not been updated on the server as yet.

Missing CodeSystem.identifier

The NCTS profile requires (Mandatory) that a CodeSystem.identifier is provided. An OID could be used here yet, unfortunately, no OID currently exists for either status. This is work to be done. I should be able to get one assigned here at the ADHA, will try and get one out of Stephen Royce at ADHA.

20160914: I still need to work on getting this OID, I need to work with Stephen Royce on this.

 

Who is the CodeSystem.publisher  

Currently, the CodeSystem.publisher is set to 'Australian Digital Health Agency'. Is this correct, should it be 'HL7 Australia'? Need discussion about this.

20160914: We agreed that the publisher would be 'Australian Digital Health Agency'.

CodeSystem.contact 

Currently set to me angus.millar@digitalhealth.gov.au but this is only temporary. A better email would be  help@digitalhealth.gov.au but it was suggested we should have more than one contact. Does HL7 Australia have an appropriate email address to also be included?  

20160914: Was agreed at the last meeting (two weeks ago) that we will set this to:  help@digitalhealth.gov.au and only that email yet maybe also a phone number also for the Agency.

 

CodeSystem.url and ValueSet.url change

We would like to get the version numbers out of the url (e.g /1.0/) as it is hardly a canonical url if it is versioned. Furthermore makes the Url's fhir server endpoint compatable. So if we were to have a Fhir server at http://ns.electronichealth.net.au/fhir then the canonical url could resolve to a fhir end point. With this is mind we are also considering weather the url should be using HL7 Australias server url i.e 'http://terminology.hl7.org.au/open/CodeSystem/ihi-status'. More dicussion needed on this point.

20160914: More discussion was had and I did some work to work out how one would retire a code in a ValueSet without need to have a version number in the canonical url. I Can see now that the retired code can continue to live on in  the CodeSystem with a property added to it that represents that the code is retired, expired or whatever you want to call it. You can then update the ValueSet to not include the code. Yet , I would be very cautious about implicit ValueSets built from the CodeSystem alone by a server as the server would not know the rules of around which Codes to include or exclude based on the properties of the code. I would suggest that in this case, of a retired code, that you always have an explicit ValueSet.

Summary is that YES we can use the 'Proposed New Namespace' url's below. 

 

Current Old proposed namespaces 

IHI Status:

CodeSystem: http://ns.electronichealth.net.au/id/hi/ihi/1.0/CodeSystem/ihi-status

ValueSet: http://ns.electronichealth.net.au/id/hi/ihi/1.0/ValueSet/ihi-status 

IHI Record Status:

CodeSystem: http://ns.electronichealth.net.au/id/hi/ihi/1.0/CodeSystem/ihi-record-status

ValueSet: http://ns.electronichealth.net.au/id/hi/ihi/1.0/ValueSet/ihi-record-status

 

Proposed New namespaces

IHI Status:

CodeSystem: http://ns.electronichealth.net.au/fhir/CodeSystem/ihi-status

ValueSet: http://ns.electronichealth.net.au/fhir/ValueSet/ihi-status

 IHI Record Status:

CodeSystem: http://ns.electronichealth.net.au/fhir/CodeSystem/ihi-record-status

ValueSet: http://ns.electronichealth.net.au/fhir/ValueSet/ihi-record-status
Posted by angusmillar at 04 Aug, 2016 15:39