Take a glance at HI Service identifier

Healthcare Identifier (HI) Service consists of three types of service identifiers:

• IHI
• HPI-I
• HPI-O

Each identifier contains 16 digit reference numbers. The identifier is created according to the International Standard [ISO7812: AS3523.1&2-2008]. You may get some ideas from wiki of ISO/IEC 7812.

The structure of the identifier has been divided into three sections:

Issuer Identification Number (1st - 6th digit):
The first 5 digits is set to be "80036" for healthcare industry.
The 6th digit will be used for types of service identifiers like IHI (defined as "0"), HPI-I (defined as "1") and HPI-O (defined as "2").

Individual Account Identification (7th -15th digit):
It contains the unique reference number.

Check Digit (16th digit):
It can be calculated using IIN and IAI. The calculation is based on the Luhn formula modulus 10 "double-add-double" check digit [ISO7812].

To assign a unique IHI, the following identifying information will be used:

• Name
• Date of birth
• Date of birth accuracy indicator
• Sex

Extra information may be included, like:

• Address (always included in verified IHIs)
• Birth plurality (where relevant, and for a designated period)
• Birth order (where relevant, and for a designated period)
• Date of death (if applicable)
• Date of death accuracy indicator
• Alias (multiple alias allowed)
• Trusted Data Source TDS identifier (Medicare Australia and Department of Veteran's Addairs identified as initial TDS)

Interim number, which can be generated at the point of care for unidentified individuals, is called provisional IHI or unverified IHI.

IHI can be classified as "verified", "unverified", "provisional", "deceased" or "retired". The HI Service will support classifications for those IHIs which are suspected or confirmed to be duplicate or replicate. An Evidence of Identity (EOI) process will be carried out to verify such initial information for the IHI.

The details of the concept of operation can be found here.

Legislation for Healthcare Identifiers Service passed by Parliament

Today, the legislation to set up the Healthcare Identifiers Service has been passed by Parliament in Australia. It means the people can have their unique identifiers for e-Health records and the organizations like hospitals and clinics will have their own unique identifiers as well. It facilitates the data exchange dramatically among various kinds of national healthcare information systems. Software render would find it easier to identify an unique patient among the sea of diverse eHRs and collaborate among the other healthcare information systems.

What a great effort, mate!

Media release

Backup: a practical point of view

In people's mind, a backup could mean a whole bunch of files to be copied and pasted somewhere. This is partly true. We can copy file-by-file or bit-by-bit. It really depends on the level of backup operation.

Here I would like to sum up a few points so hope the people around may know more about the backup operations of a system.

There are three kinds of backup operations to be carried out in order to keep the system running well. What it means by running well is that the system is running with practically up-to-date data, managed application source code and working opearting system files.

Data backup makes sure the data collected by the system is practically up-to-date. The backup target is specific to the master database server. To fulfil a high level of service uptime, the backup operation is carried out in the offline secondary (slave) database server which synchronizes the data with online master database. Carrying out such data backup operation will lead to a drop of overall system performance so we need to schedule it carefully and avoid any peak time of service demands. The principle is keeping minimum but most recent copies of backup as you can.

Backup of application source code can be done through using SVN server which provides the version control over the source code and maintains different versions of the source code among Production server, Test server, and Development workstation. It makes sure the source code can be reverted to a particular version on Production server at any time, assuming that this particular version of source code to be compatible with the current structure of database.

Backup of opearting system files keeps up-to-date software and configuration settings on currently workable state of Production server. It mainly includes software update, custom configuration settings and scheduled tasks for maintaining service uptime and data backup operation. This is extremely useful when a disaster recovery is not triggered by a minor incident at the data centre. The reason is that disaster recovery is defined as fire, flooding and physical damage to the equipment in the data centre. Lower level of disaster like incorrect system configuration and third-party software installation would not trigger such recovery process but can lead to a corrupted system state which makes Production server non-workable. In this case, the data centre has no choice but retrieves the initial image copy of the server which is out-dated and needs to be applied all the patches, settings and scheduled tasks again to make it workable. Regularly taking system snapshots of Production server can shorten the time to recover the service. In a virtual environment like VMware, the snapshots of system state can be taken in a regular schedule while Production server is running. The reverting process to previous system state is quite handy and can be efficiently handled by any VMware administrator. This is part of business continuity features by using virtualization technology. To meet a requirement of business continuity, the system administrator should schedule the tasks to take system snapshot of Production server at regular period. It ensure that a reasonable system state can be recovered in case of the aforementioned incidents.

All those backups ensure that the system state can be kept practically up-to-date after the recovery from most incidents.

Import/Export BLOB data type correctly in MySQL database

MySQLDump is one of the built-in tools which is useful enough for data import/export on daily operation. To deal with complex data types like Binary or BLOB, it is good to export them in HEX code in order to avoid any invalid character set issue or corrupted data during data import.

MySQL manual has already mentioned about this:

http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html#option_mysqldump_hex-blob

--hex-blob

Dump binary columns using hexadecimal notation (for example, 'abc' becomes 0x616263). The affected data types are BINARY, VARBINARY, the BLOB types, and BIT.

Gnome Network Manager - A must read note

When trying to figure what's happening for my NetworkManager settings being in-consistent with the settings in original interface control file /etc/network/interfaces, I found this note:

Why won't Network Manager manage my Networks?

If your network connection is listed in /etc/network/interfaces, it is unavailable to NetworkManager with it's default setup (read this to see how to change it to manage these connections: http://wiki.debian.org/NetworkManager ). The best option for a standard setup is to open the file using

sudo gedit /etc/network/interfaces 

and comment out (ie put a # in front of) or delete every line in the /etc/network/interfaces file except the two with lo in them- they read

auto lo
iface lo inet loopback

Things are you really want to manage static IP yourself. Then you add new line in /etc/network/interfaces, remember, but not in Network Manager. Any non-dhcp (static) interface in /etc/network/interfaces will not be governed by NetworkManager. Then you may ignore the alert icon on NetworkManager even if you have connection access to the outside with your static interface settings.

Fix MAC address to eth0 mapping issue on Debian based Guest VM

When using VMware server/ESXi in production environment, new MAC address is allocated to a new VM being added. Same situation happens on the same VM if it is configured to have new network adaptor. A different MAC address is allocated to that network adaptor and it never duplicates. Debian based Linux will automatically map this new MAC address to a different network interface, i.e., eth? (where ? is always greater than 0) In this case, it will never map back to original network interface, say, eth0.

Now check the file "/etc/network/interfaces", the content should be:

Assuming you always have one network adaptor installed on your system and that one is expected to be eth0:

To make sure new adaptor's MAC address being mapped to eth0 network interface, there is a file that raises such interest:
"70-persistent-net.rules"

I don't know what's 70 means but it always appears when you have network adaptor installed on your system.

Try issue following command to locate this file in your linux environment:

This file is created by udev service at startup where auto detection of network adaptor takes place. New content will be added to the bottom of the file automatically. It determines the output results you could find by issuing ifconfig command.

In this case, eth2 is active, not for eth0.

Basically, the file "70-persistent-net.rules" contains all the detected PCI devices and then do the mapping with them. Here is a typical one:

Well, obviously you will find it useful to have a look at the NAME key paire whereas eth0 is specified. Meanwhile, assigned MAC address (either physical or virtual one) is shown after ATTR{address}.

This kind of settings will be accumulated along the time when new network adaptors are added or MAC address is changed. New string with NAME="eth?" will be added to the end of the file so we can tell from the aforementioned file that the MAC address has been changed twice and finally eth2 becomes the current active network interface.

If you want to force new MAC address being mapped to eth0 network interface, you can delete this file, namely "70-persistent-net.rules", with the following command:

Then modify the content in "/etc/network/interfaces" to substitute eth2 with eth0:

After system reboot, you will find a brand-new "70-persistent-net.rules" file reappearing in the directory but the content will be:

Now, the network adaptor is mapped to eth0 again.

For the administrative point of view in VMware environment, it is not a good practice to manually reset network interface mapping like this. That would be good if we can automate it. Here is how:

• locate directory "/etc/init.d"
• pick one of networking related script like "/etc/init.d/networking" and edit it
• locate stop) section within script file "/etc/init.d/networking"
• add the following line towards the end of the section (right before double semi-colon ;;):
• save it
• If you find a symbolic link linked to this script file within /etc/rc0.d/ directory, then it means it will run stop) section of "/etc/init.d/networking" during system shutdown process, i.e., deleting "70-persistent-net.rules" automatically. If not, you may need to create a symbolic link yourself within /etc/rc0.d/ directory. The command would be like this:

$ sudo ln -s /etc/init.d/networking /etc/rc0.d/networking

Now, everything is ready. Try reboot the system to let things happen.

Whenever MAC address is going to be changed at next bootup, the problematic "70-persistent-net.rules" file would have been deleted first during shutdown period. Then a new "70-persistent-net.rules" file will be created with the correct mapping of MAC address to eth0 again at next startup. It makes sure new MAC address is always mapped to eth0 adaptor, with the basic assumption that there is only one network interface card installed on the system.