Electronic Medication Management Systems – Overview

An EMM system is a system of prescribing, supplying and administration of medications. All the medication activities doctor prescriptions, review and dispense by a pharmacist, and administration by nurse are managed through this system.  EMM system increases patient safety by improving prescription legibility, right amount of dose calculation, and clinical decision support thus reduces medication errors.  EMM system ensure safe onscreen display of information related to particular medication, error alerts and dose calculators with prompts to check certain pathology or clinical information with certain drugs.  EMM system refers National Tall Man Lettering list when prescribing similar sounded medicines to distinguish from one another. For example niFEDIPine and niMODIPine are two similarly sounding drugs.

A well implemented EMM system with standards would implement the following main categorical functional components for better medication management and clinical support decisions.


a) Access to latest pathology results : When making decisions on medication orders, it is important to access latest pathology results to interpret the reason or indication.

b) Access to latest patient clinical information : It is important to access latest patient clinical information such as blood pressure, pulse, weight etc. to assist in medication orders and clinical support decisions.

c) Access to previous and current medication records : Access to previous and current medication records such as previously ordered, administered, ceased or withheld is required to fully inform clinicians.

d) Recording of medication history on admission  : Medication history such as prescriptions, over the counter and complementary medicines along with dosage quantity, frequency is recorded.

Medication orders

a) Selection of medicines and directions : System ability to allow prescribers to select medicine names, form, frequency, route, strength, dosage and duration of therapy.

b) Allergy and adverse drug reaction(ADRI) information : System ability to present patient allergy information and ADR status when patient initially registered.

c) Public hospital formulary : System ability to restrict ordering of certain medicines to certain prescribers according to local public hospital formulary. For example cytotoxic medicines limited to oncology specialities, restricted antibiotics to infectious diseases specialists.

Clinical decision support

a) Active alerts : System ability to present active alerts such as prompts, reminders, error alerts etc. at the time of decision making.

Medication dispensing

a) Recording of medicines dispensed : System ability to record medicines dispensed. This helps clinicians to review new medication orders.

Medication Compliance App

Medication compliance and adherence are the two main issues have to be handled when dealing patients with chronic illness such as diabetes, asthma, cardiac condition etc. Medication compliance refers to the degree to which the patient follows a health provider advice correctly and adherence refers to the behavior of patient related to that advice such as prescription fills and refills on time. Both medication non-compliance and non-adherence may have serious effects on the patient health and chance of relapse.

The common reasons associated with medication non-compliance and non-adherence are as follows

1) Patients such as elderly does not remember medication schedule.

2) Patients doesn’t follow directives deliberately

3) Taking medicines at wrong time and in wrong bio state for example empty stomach, after dinner etc.

4) Too many medications prescribed which results in confusion.

5) Failed to order and fill prescriptions

6) Stopping medications after disappearance of symptoms.

Review of an existing solution

I have reviewed an existing solution MedicineList+ developed by NPS medicine wise, an Australian based not-for-profit and evidence based organisation.

The primary features of this solution are

1) Patients can order prescriptions from the participating pharmacists and download prescription records.

2) Manages multiple patient profiles on a single device.

3) Maintains a record of allergies and reactions, conditions, measurements and test results.

4) Generates a health graph and report and sends an email to the configured health care provider.

5) Ability to add medicines and reminders.

Users and Roles

Patient Patient with any chronic illness that requires strict medication.
Pharmacist Pharmacists are responsible for taking orders and dispensing medications to the patient and providing professional advice.
Doctor Doctor recommend/advice the prescriptions and schedule.
Nurse Nurse are responsible for monitoring patient medication.
Families Family members may monitor patient medication by subscribing to alerts in the form of SMS and app alerts if the patient misses medication at any particular time.

Data Flow


Functional points

1) Create a patient profile

A patient can create a basic profile with name, contact information and picture. Multiple profiles are allowed.

2) Add medicines

Patient can add a medicine manually by searching from list or scan a barcode of the medicine. Currently it is allowing only one medicine at a time. Patient can also enter non-prescribed medicines.

3) Download prescription records from pharmacy

Patient can download prescriptions list from pharmacy at any time with a six character unique linking code generated by the app.

4) Set reminders

Patient can configure reminder alarms at specific intervals in the specific time zone.

5) Add allergies and reactions

Allergies and reactions plays a significant role in patient’s safety.

6) Add Notes

Patient can add any notes.

7) Add measurements and tests

Patient can add measurements and test results.

8) Add health provider details

Patient can add health provider details with name and email. All the reports are sent to the configured email address.

Pain Points

1) Backup

If the phone stolen or data corrupted, patient has to re-enter everything and may not be able to remember the last medication status such as doses remaining etc.

2) Device change

If the patient decides to use a new phone in the place of existing one, there’s no way to transfer data from old one to the new one. They have to re-register with their pharmacy and import all the past as well as new prescription records along with dosage rules. But same cannot done in the case of historical data such as past vital statistics and doses.

3) History

Health provider cannot view historical data such as medications, dose usage, measurements and test results. Historical data can be used for analytical purposes and helps in decision making processes.

4) Security

Current app stores information on device for offline access raising security concerns. Any patient data treated as sensitive so adequate security measures have to be implemented in order to prevent invasion of privacy.

A Better App?

This one is in my priority list. Currently I’m working on a prototype solution that  covers functional points and would address all of the pain points as well.

Understanding HL7 transports – ebXML vs MLLP vs WS

The selection of any of the transport specifications ebXML, MLLP and WS for exchanging HL7 messages depends  upon the key features Security, Addressing, Routing and Reliability.

The following table shows the availability of various features in each of the transport specifications

Feature ebXML WS MLLP
Addressing Yes Yes No
Routing Yes Yes No
Reliable Messaging Yes Yes Yes
In-order delivery Yes Yes Yes
At-Most-Once delivery Yes Yes Yes
Security Yes Yes No
Integrity Yes Yes No
Confidentiality Yes Yes No
Non-Repudiation Yes Yes No
Authorization Yes Yes No
Authentication Yes Yes No
Auditing Yes Yes Yes
Encryption Yes Yes No
HL7 v2 support Yes No Yes

Understanding HL7 transports – ebXML

ebXML is a family of XML standards developed by OASIS (the Organisation for the Advancement of Structured Information Standards) and UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business) to provide an interoperable, secure an open XML based infrastructure that enables the global use of electronic business information for all the trading partners. It enables traders to implement e-business solutions for exchanging data in an agreeable format with others.

HL7 uses ebXML message package to provide a secure, flexible transport for exchanging HL7 messages and other content. For exchanging ebXML message packages, both the sender and receiver have to implement interface handlers (MSH) for ebMS (ebXML Messenger Service) with agreed communication protocols such as HTTP, SMTP and others. ebMS is just an abstraction of process rather than a physical component and providers facilities such as message packaging, routing and transports for the ebXML infrastructure.

By default security and reliability features are not included in the base SOAP and SOAPAttach specifications due to their limitations. ebMS extends SOAP and SOAPAttach specifications with a set of layered extensions to address specifically the security and reliability features based on WSS security and WS reliability for support international electronic businesses and are approved as ISO 5000-2 standards . The message package which contains the message enveloping and header document schema along with their behaviors to transfer ebXML messages over communications protocols.

The message package structure supports two types Simple Soap Style and Multipart Mime Style

Simple Soap Style contains a simple SOAP Envelope with SOAP Header and SOAP Body elements. The message payload is placed in the SOAP Body element.  However, Multipart Mime Styles contains contains MIME headers with multiple mime parts where SOAP headers are placed in first mime part and message payload placed in one or more MIME parts following first MIME part.  Multipart Mime Style is more specifically used for SOAP messages with Attachments i,e. SOAPAttach.

Simple Soap Style


Multipart Mime Style


Message exchange patterns

ebMS supports two message exchange patterns to exchange message reliably based on WS-Reliability.

1) Notify – Sender MSH just sends a payload to the receiver MSH and doesn’t expect any response.

2) Request/Response – Sender MSH sends a payload to the receiver MSH and expects a response. The errors during exchange if any may be reported back through a HTTP Response code, a WSR response message, an ebXML Signal Message or User Message.


ebMS specifications for HL7 has following restrictions

1) MSH supports different types of messaging patterns. However, for HL7 only two message exchange patterns supported One-Way/Push Notification style messages and Two-Way/Sync for Request-Response exchange.

2) SOAP message MUST have an XML Prolog and UTF-8 encoding.

3) For all Request-Response synchronous exchange messages requires HTTP(s) transport protocol.

4) No Schema hints are allowed in the wire format of messages. They will be ignored if included.

5) Only default Message Partition Flows(MPF) is allowed for exchanging all the User Messages.

6) Only SOAP 1.1 is allowed. In future SOAP 1.2 may be allowed in later versions.

Duplicate Message Handling

To handle duplicate messages, all the nodes engaged from originator to the receiver SHALL implement a persistent storage mechanism to detect and supress forwarding of duplicate messages if suppression is requested. The suppression request is included with DuplicateElimination of Request element in SOAP header. Duplication is detected by comparing ebXML SOAP headers or message id’s or message data timestamps.

Understanding HL7 transports – MLLP

Systems exchanges HL7 messages using a variety of TCP/IP transports including MLLP, HLLP, SOAP, SMTP, FTP and even HTTP. The most common type of transport used is MLLP ( Minimum Lower Layer protocol )  which sometimes referred as LLP without ‘M’ or simply MLP.

The MLLP protocol is a minimalistic OSI-session layer framing protocol which is extensively used for the transport of HL7 version 2 and 3 messages. This protocol doesn’t require any supplementation for error detection and correction which are handled by underlying TCP/IP protocol.

This protocol uses special block markers at the start and the end of every HL7 message exchanged. The sender prepares HL7 content with start block marker <SB> and end block marker <EB> followed by a carriage return <CR>. The receiver decodes <HL7 message> by stripping these markers. This one is normal behaviour for exchanging HL7 version 2 messages. However, HL7 version 3 messages requires an acknowledgement or negative acknowledgement of 4 bytes from the receiver to sender with a ACK value in the case of success where as a NAK value in the case of failure. Both ACK and NAK enclosed by the special block markers <SB> and <EB> followed by a carriage return <CR>. This ensures a guaranteed exchange.

The MLLP transport protocol uses the following formats for exchanging HL7 version 2 and version 3 messages.

Version 2

<SB> <HL7 message> <EB><CR>

Version 3 requires additional response from the receiver in the following format.

<SB> <ACK | NAK> <EB> <CR>

The receiver always sends a response to the sender which sometimes referred as commit acknowledgement to guarantee In order delivery and At Least Once delivery of HL7 content.


Element Description
<SB> Start Block character of length 1 ASCII byte 0x0B
<HL7 message> The actual HL7 message to be exchanged in bytes. Each message contains variable number of bytes
with values greater than 0x1F followed by ASCII carriage return <CR>. Version 2 uses HL7 message in segments fashion whereas Version 3 always use in xml form.
<EB> End block character of length 1 ASCII byte 0x1C
<CR> A carriage return of length 1 ASCII byte 0x0D
<ACK> Acknowledgement of length 1 ASCII byte 0x06
<NAK> Acknowledgement of length 1 ASCII byte 0x15

Both sender and receiver are implemented with validation checks to ensure messages are exchanged in agreeable format such as Block markers, encodings, timeouts etc. Additional processing is done by the sender depending upon the type of acknowledgement.



Version 2

^^P||""|""||""|||||||""|""<CR>PV1||I|3w^301^""^01|S|||100^van den Berg^^A.S.

Version 3

<?xml version="1.0" encoding="ISO-8859-15"?>
	<MFMT_IN10001NL xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc" 
	<id extension="10213" root="2.16.840.1.113883."/>
	<creationTime value="20050216140000"/>
	<interactionId extension="MFMT_IN100010NL" root="2.16.840.1.113883"/>
	<processingCode code="P"/>
	. . .
	. . .



Negative Acknowledgement


NEHTA Overview and Its Impact on health services

National E-Health Transition Authority is an Australian and state government’s funded lead organisation formed to support and oversee Australian national vision for e-Health. It provides necessary infrastructure and solutions to form a secure, safe and efficient health system to be used by providers and patients.

PCEHR Infrastructure

Australian patient’s medical information is distributed among various health care providers including hospitals, specialists, imaging clinics, aged care centres etc. This information is critical when providers doing assessments for some conditions and also for medication purposes. The main concern is patients do not have any access to their information as it is maintained by providers independently and exchanging patient information is sometimes complex in nature.

To overcome difficulties with the patient information and to make it more agile and sustainable, Australian government introduced PCEHR electronic system to store and maintain patient information from multiple providers at one place with safe and secure access.

PCEHR is an electronic system that stores patient record including their medical history from time to time collected from various types of providers and other organisations such as Medicare.

Every PCEHR record associated with each patient contains the following

1) Personal details

Records patient personal and emergency details

2) Clinical documents

Records patient clinical documents such as imaging, pathology reports etc.

3) Medicare records

Records patient Medicare claims and other relevant information.

4) Medicine records (eMedication)

Records patient dosage and dispensing history

5) Child development

Records patient child development related information.

6) Restricted settings

Records restricted settings used by patient to control access to their records by external providers and nomination details.

7) Access history

Records the access history containing details about who and when accessed.

Healthcare Identifiers (HI)

Healthcare identifiers (HI) Service developed by the federal, state and territory governments that uniquely identifies healthcare providers and consumers. These identifiers are important building blocks of E-Health in Australia and used to enable PCEHR system and are used on medical documents, patient wrist bands, tokens etc.

The HI service is mainly used by

· Public and private sector hospitals

· General practice

· clinical specialist

· community health

· healthcare administrators

· allied health

· aged care settings

Healthcare identifiers are categorised into the following

Individual Healthcare Identifiers (IHI) – For individuals receiving health care

Healthcare Provider Identifier – Individual (HPI-I) – For healthcare providers and personnel involved in patient care

Healthcare Provider Identifier – Organisation (HPI-O) – For organisations that deliver healthcare (hospitals or medical practices)

Each identifier is a unique number adhered to ISO7812: AS 3523.1&2-2008 standards and is of 16 digits in length. It doesn’t contain any identification information such as age, location etc. and never be re-used.

The first 1-6 digits contains issuer identification number (for example Medicare) and 7-15 digits contains a unique reference number that identifies an individual. The last digit 16 is reserved as check digit which can calculated from issuer identification and individual reference number.

The main functions of a HI service are

· Allocating IHIs, HPI-Is, and HPO-Is,

· To allow authorised users to search, retrieve and validate IHIs, HPI-Is, and HPO-Is

· To allow authorised users to maintain and publish certain data (allowed only with HPI-Is and HPO-Is)

· To provide digital certificates for access

· Retiring identifiers

E-Health software systems engaged in health care uses HI service to issue, assign and maintain national healthcare identifiers for consumers and providers. These systems access HI service directly or indirectly (depends on the other systems which have direct access to HI). All the systems should undergo conformance testing (CCA) performed by NATA recognised laboratories to prove it supports clinical safety, security and privacy.


NASH delivers a secure and authenticated service to exchange e-health information for all Australian healthcare organisations and other e-health personnel. It provides the necessary infrastructure, framework, and technology and support services for both health care organisations and vendors for issuing secure credentials that can used for digitally signing various types of e-health transactions such as electronic prescriptions, hospital admissions and discharges, and reports which can be exchanged with others in a secure and safe way.

With NASH PKI certificates, providers authenticate themselves with the PCEHR system and digitally sign health information to ensure they are not tampered. Each PKI certificate stores provider HI identifiers and other registration information.

NASH credentials are supplied to authenticate themselves in different ways by different consumers either by using smart cards or usb’s or pc installed software.


NASH credentials for individual providers such as doctors and other healthcare professionals are typically in the form of smart cards or tokens. They store individual HPI-I number by embedding in the device.

clip_image002 clip_image004

Individual providers uses the above devices

1) To access patient e-health record from PCEHR

2) To access information from NASH directory


For healthcare organisations such as public and private hospitals are provided with credentials on a CD labelled as NASH. Each CD contains software PKI certificates that are stored with organisation HPI-O number


Organisations uses NASH PKI certificates

a) To access patient health record from PCEHR.

b) To digitally sign the electronic communications when exchanging with other healthcare provider organisation.

c) To access NASH directory.

Supporting Organisations

Support organisations provide services to health care providers to access, send and receive information securely. They are registered as CSP or GSO. Each CD contains PKI certificate with organisation registered number.


Support organisations uses NASH PKI certificates

a) To digitally sign the electronic communications when exchanging health information between various healthcare providers.

b) To access NASH directory

Putting All Together

Patient registers in PCEHR system by providing personal, Medicare and bank details through MyGov account. PCEHR creates a patient record and links with Medicare system. It also creates a unique HI identifier IHI for the patient to access PCEHR system. Providers registers with HI service to obtain unique HPI-I or HPI-O identifiers to access PCEHR system and NEHTA provides with NASH PKI certificates with their HI identifiers embedded in them in the form smart cards or usb’s or CD. Providers must use a PCEHR compliant software to configure their PKI certificates. Patient engages with a provider and provides his IHI identifier. Doctors uses PCEHR compliant software to access patient record identified by IHI identifier from PCEHR system by authenticating themselves with NASH PKI certificates. PCEHR system verifies NASH PKI certificates received from providers and grants access to patient record and logs details about provider access in patient record. Provider refers to other providers (specialist or imaging) electronically by digitally signing and exchanging patient information. Other providers uploads clinical documents to PCEHR system.


Australian health care providers are using different vendor and customised software’s to provide various services to patients. NEHTA provides necessary infrastructure to maintain patient e-health records in a centralised storage and provides access to providers to access and update these records on patient engagement.

The impact of NEHTA infrastructure on health services varies from one end to other. Patients and providers are not legally bound to participate in government e-Health system as the participation is voluntary but have numerous benefits to both as the system promotes single view of truth at any point of time.


Without PCEHR, patients cannot view their up to date information recorded against an engagement with each provider. If they change provider, they can’t access their past information conveniently at any time and subjected to provider’s policies.

Patients can register with PCEHR by creating a MyGov account with their Medicare details, address and bank details. Once registered, patients can view their medical records, clinical documents, Medicare details, and access control information. They can control access to their eHealth records for the selected providers however they cannot update medical related information but only settings and personal information.

Patient can access up to date information about their medical history. It improves patient awareness and provides valuable insights during assessment.


There will be significant impact on the existing health services as it improves the service by providing a centralised record management and accessing up-to-date information about patients from time to time.

Providers have to register with NEHTA to get HPI-I or HPI-O identifiers which can be used to access and update patient information using NASH certificates and digitally sign information when exchanging with other providers related to patient. It’s not only improve the service to the patient but also reduces time taken to deliver the service as providers can exchange information with other providers electronically without doing any involvement of paper work. Its work well in multidisciplinary settings involving doctors, radiologists, and clinicians. Majority of the software vendors already implemented PCEHR capabilities in their systems used by the providers.

Abbreviations and Acronym’s

PCEHR Patient Controlled Electronic Health Record
NEHTA National E-Health Transition Authority
NASH National Authentication Service for Health
HI Healthcare Identifier
PKI Public Key Infrastructure
CSP Contracted Service Provider
GSO General Supporting Organisation
CD Compact Disk

DICOM overview

DICOM (Digital Imaging and Communications in Medicine) is an international standard used for storing, integrating and exchanging medical image data. DICOM is mainly used in radiology, cardiology imaging, x-ray, CT, MRI etc. and one of the widely used medical standards by clinicians in the world.

DICOM was established in 1982. Back in olden days exchanging medical images from one device/software to other was a cumbersome process because of different formats adopted by device. It involves conversion of source image into target device specific format. Also storing images with patient information. DICOM created to solve these compatibility issues. The main purpose of this standard is to enable interoperability among various medical devices/software’s to create, exchange and view medical image files without any specific conversion.

This standard is maintained by a committee comprising of 25-30 companies, 10-12 user organisations, and 6-8 general interest members. NEMA (National Electrical Manufacturers Association) holds the copyright and oversees day to day operations, publications and legal problems. The standards committee is responsible for developing and voting proposed standards and adopting policies and procedures.

The ACR(American College of Radiology) oversees the technical and medical instructions. DICOM is an integral part of IHE(Integrating the Healthcare Enterprise). DICOM standards committee jointly works with HL7 group and ISO’s TC 215.

Several formats available in market to represent images namely JPEG, PNG, GIF etc. This formats doesn’t allow to store extra information and provide the ability to search inside the image for particular pattern. Each medical image should be associated with patient information and other required extra information specific to the device from which it is captured. DICOM allows to store patient and extra information and search functions. This way when exchanged other clinicians can identify patient from the image data.

DICOM standard consists of specifications for

  1. Defining images including its structure : Basic format how the image data stored with extra information
  2. Network protocol: Specifications for network services
    • Archive service – to search an image in the system
    • Print service – to allow access to the network printers
    • Modality work list service – To allow to download latest work lists with patient demographic data from other systems
  3. Formats for exchanging – how the two parties agree on the format for exchanging with compression and other information.
  4. Conformance specifications: Each independent device or software that supports DICOM must conform to the minimum set of conformance specifications.

A DICOM file contains

  1. Header
  2. Data elements

Header is repeated only once and is sometimes optional. It consists of 128 preamble and 4 byte prefix. Data elements are repeated and each one associated with a tag. Group of data elements forms a data set and are ordered by data element tag number.

Each of this data element consists of

  1. Patient information with name, sex, identification number
  2. Device parameters, scan type
  3. Image information such as resolution, windowing, width and height

HealthCare Identifiers for Individual and Provider

Recent National E-Health implementation added additional identifiers IHI, HPI-I and HPI-O can be used for an individual and provider on top of existing identifiers such as Medicare, Insurance etc. Different identifiers are used for different purposes for example insurance identifier is used when sending  insurance information to identify specific individual, IHI number used when accessing PCEHR, organisation may use one Medicare number for billing purposes and other for administrative purposes.

Australian standards provided new set of guidelines in 2014 to accommodate these identifiers in the health systems.

Every identifier should be associated with the following when stored 

  • Identifier designation : This refers to the actual identifier code

Example: IHI number or Medicare number

  • Identifier Issuer:  Name or HPI-O of the issuing authority

Example: Medicare, Centrelink, 8003621566684455

  • Identifier usage : The purpose of using the identifier

Complete list of identifier usages

110 – Individual Healthcare Identifier (IHI)
112 – Healthcare Provider Identifier—Individual (HPI-I)
113 – Healthcare Provider Identifier—Organisation (HPI-O)
114 – Virtual smart card identifier (CSP)
120 – Family Identifier
200 – Billing Identifier
300 – Business or Individual Taxation or Social Security Identifier
400 – Special Service Identifier (e.g. diagnostic services)
410 – Laboratory Services
420 – Radiology Services
480 – Other Diagnostic Services
500 – Individual Provider Identifier—other than the national number
600 – Organisational Provider Identifier—other than the national identifier
700 – Professional Registration Identifier
800 – Other
900 – Unreliable

  • Identifier Usage Start Date: Start date of the identifier usage, the date on which using this identifier began or will begin.
  • Identifier Usage End Date: End date of the identifier usage, the date on which using this identifier ended or will end.
  • Identifier Status :  Status of the identifier

Examples: Active, Inactive

  • Identifier Group : Group of the identifier

Examples: F (Family), T(Treatment), O(Other)

I think it is essential for all the health systems in the current market used by providers (practice management, EMR, EHR etc) to accommodate these identifiers to meet the identification standards. It will be interesting to see how the existing health systems such as ZedMed, Communicare etc. conforms these standards.

Australian HealthCare Identifiers and Service

Healthcare identifiers (HI) Service developed by the federal, state and territory governments that uniquely identifies healthcare providers and consumers. These identifiers are important building blocks of E-Health in Australia and used to enable PCEHR system and are used on medical documents, patient wrist bands, tokens etc.

The HI service is mainly used by

  • public and private sector hospitals
  • general practice
  • clinical specialist
  • community health
  • healthcare administrators
  • allied health
  • aged care settings

Healthcare identifiers are categorised into the following

  1. Individual Healthcare Identifiers (IHI)  – For individuals receiving health care
  2. Healthcare Provider Identifier – Individual (HPI-I) – For healthcare providers and personnel involved in patient care
  3. Healthcare Provider Identifier – Organisation (HPI-O) – For organisations that deliver healthcare (hospitals or medical practices)

Further IHI is classified into the following

  1. Verified – Evidence of Identity(EOI) completed through TDS(Trusted Data Sources) or HI service
  2. Unverified – Not verified by EOI process
  3. Provisional – Not known to healthcare facility and expires in 90 days
  4. Deceased – Indicates death of an individual
  5. Retired – IHI has been inactive for 90 days and Fact of Death Data received from Registrar of Births, Deaths and Marriages.

Each identifier is a unique number adhered to ISO7812: AS 3523.1&2-2008 standards and is of 16 digits in length. It doesn’t contain any identification information such as age, location etc. and never be re-used.

The first 1-6 digits contains issuer identification number (for example medicare) and 7-15 digits contains a unique reference number that identifies an individual. The last digit 16 is reserved as check digit which can calculated from issuer identification and individual reference number.

The main functions of a HI service are

  • Allocating IHIs, HPI-Is, and HPO-Is,
  • To allow authorised users  to search, retrieve and validate IHIs, HPI-Is, and HPO-Is
  • To allow authorised users to maintain and publish certain data (allowed only with HPI-Is and HPO-Is)
  • To provide digital certificates for access
  • Retiring identifiers

E-Health software systems engaged in health care uses HI service to issue, assign and maintain national healthcare identifiers for consumers and providers.  These systems access HI service directly or indirectly ( depends on the other systems which have direct access to HI). All the systems should undergo conformance testing(CCA) performed by NATA recognised laboratories to prove it supports clinical safety, security and privacy.

Algorithms for DNA related analysis – Introduction

Before discussing about algorithms, I will discuss some frequent terms used in DNA analysis. I’m not a biological student but one who uses algorithms  for DNA mappings, sequencing related analysis need to understand frequently used terms around DNA

  • Amino acids
  • Proteins
  • Nucleic acids
  • Genome
  • Transcription
  • Translation
  • DNA replication

Amino acids

Amino acids are chemical compounds which are building blocks of proteins and act as intermediates in metabolism. Protein characteristics always dependent on the amino acids precise content and their sequence. It means each protein has different amino acid contents and sequence. Also the chemical properties determine protein biological activity. To understand a protein structure and its stability (protein folding), it is essential to understand amino acid structure and chemistry first.

There are 20 types of amino acids within a protein 10 of which can be produced by human and other 10 are supplied through food. Human body doesn’t store excess amino acids (those available from food) like fat and starch so they should be available through food daily.

Recent study findings on insulin resistance for diabetes type 2 patients revealed that lipids and Branched-Chain amino acids (BCAA) work together to promote metabolic diseases. The presence of BCAA related signature is predictive of incidence, progression and remission of diabetes and insulin resistance.


Proteins are complex molecules that are made up of smaller unit’s amino acids as a long chain. Proteins can be categorized into types based on their function, few of the types are

  1. Antibodies – attaches to virus to protect the body
  2. Enzymes – Assist in the formation of new molecules from the DNA information
  3. Messenger – to transmit signals between cells, tissues and organs
  4. Structural component – Used for cell structure and support.
  5. Transport/storage – Carry atoms and molecules around the body
  6. Proteins can synthesised using two ways
  7. Biosynthesis – These are synthesised in cytoplasm from encoded gene instructions
  8. Chemical synthesis – These are synthesised chemically with peptide synthesis

A simple good example is identifying antibodies in the blood for determining HIV existence in the patient’s body

Nucleic acids

Nucleic acids are essential molecules of life. They include DNA (deoxyribonucleic acid) and RNA (ribonucleic acid) which are made from nucleotides. Each nucleotide consists of 5-carbon sugar, a nitrogenous base and one or more phosphate groups and categorised as DNA or RNA depending upon the sugar component. If the sugar component is deoxyribose, then it’s a DNA or if sugar component is ribose, then it’s a RNA.

DNA consists of two long strands of nucleotides which are anti-parallel in nature (opposite direction)

RNA plays an important role in protein synthesis and is divided into three types

  1. Transfer RNA (tRNA)
  2. Messenger RNA (mRNA)
  3. Ribosomal RNA (rRNA)

DNA and RNA contains sequence of genetic instructions that are essential for encoding cells, organs etc.


A Genome is encoded DNA genetic material of an organism which contains all the information needed for building and maintaining the organism. It is estimated humans contains more than 3 billion DNA base pairs in all the cells that have a nucleus. A genome contains set of instructions needed to build cells. Each one will have two types of

Genome sequencing and matching helps the analysts in predicting and matching like DNA. It is nothing but decoding genetic sequence in the form four letters A C G T. With newer technologies, sequencing became very cheaper when compared a decade ago.

Scientists uses genome compositions to study evolution history of genomes by comparing the proportion sizes of repetitive DNA and non-repetitive DNA.

Transcription is a process of creating a copy of mRNA (messenger RNA) from a DNA gene sequence. This mRNA enters cytoplasm after leaving cell nucleus. Cytoplasm direct protein synthesis according to encoded instructions stored in mRNA.

DNA contains two strands sense and antisense. mRNA is actually a single stranded unlike DNA and a compliment of antisense strand of DNA (template strand).

Transcription is done with the following steps

  1. Pre-initiation –
  2. Initiation
  3. Promoter clearance
  4. Elongation
  5. Termination

There is a process called reverse transcription in which RNA is transcribed into DNA (opposite of DNA to RNA). This behaviour usually found in viruses such as HIV etc.


Translation is a process of decoding and translating instructions from messenger RNA (mRNA) to direct protein synthesis. It converts gene sequence to amino acids sequence with the help of ribosomes and transfer RNA which in turn forms proteins.

Translation is done three steps

  1. Initiation
  2. Elongation
  3. Termination

Detailed steps involved in translation

  1. DNA transcribes genetic information by creating mRNA
  2. mRNA leaves cell nucleus and enters into cytoplasm
  3. mRNA carries genetic instructions from chromosomes to ribosomes
  4. Ribosomes assembles and translates genetic information to sequence of amino acids provided by tRNA
  5. A protein is formed based on amino acid sequences

DNA replication

DNA replication is process of replicating two identical DNA helices from the original DNA helix. This process is required in every living organism to carry out the following functions

  1. To build and regulate the cell from the encoded genetic information
  2. Genetic information transmission from one generation to other

The replicated helices are called as daughters and original DNA helix is called as parent. Parent strand is divided into two strands and a complimentary strand is created for each separated strand thus forming a daughter. This process is called as semi-conservative because each daughter contains one parent strand and one complimentary strand of parent strand.

By studying DNA replications, researchers were able to find the relations between certain disease behaviours. A recent example of this type of study is presence of DNA replication stress in human cancers. Human cancer is characterized by genomic instability. From the study, it was proved oncogene-induced DNA replication stress rises genomic instability in human cancers (increases deletions in common fragile sites). As a result genome copy number changes.

In the next part, I’ll discuss various algorithms and tools used for DNA analysis.