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 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.

The usage of mobile devices for radiology purposes increased in the last few years with the availability of smartphones. The first mobile app used for radiology purposes was approved by FDA in 2011 after an initial rejection in 2010.

A mobile device with smart phone capabilities can be used as an alternative medical device with limited features that can accessed from anywhere without depending on a desktop client. However, it’s not a complete replacement for desktop pc but still need a desktop pc to perform some complex tasks.

A Radiology information system (RIS) is an integrated suite of various software components responsible for patient management, workflows, reports, orders and billing, authorisation, image storage (PACS) etc. The main purpose of RIS is to manage radiology activities from referral request to scanning to report. The patient management module is either internal or external integrating with hospital information system or EHR.


In this comparison study, range of functionalities implemented in mobile apps to access radiology based information by each RIS vendor will be compared and discussed. The scope of comparison was limited to 3 Australian based RIS vendors namely Kestral karisma, GE Centricity, I-MED.

Kestral computing is an Australian operated organisation developing radiology and pathology solutions. Its flagship product karisma is a web based RIS application with features accounting, reporting, dictation etc. It developed a mobile app Karisma mobile to access its RIS server from iOS and Android platforms based devices.

GE healthcare is a unit of GE Australia providing medical technologies and services. GE centricity RIS-IC is RIS web application developed by GE healthcare. It’s integrated with GE Centricity PACS solution to implement patient centric workflow management in radiology. It developed a mobile app AccessNow to enable limited functionality of its integrated RIS server accessed on iOS and Android platform based mobile devices.

I-MED Network radiology, an Australian network of medical imaging clinics providing radiology services. It developed I-MED mobile app to access its RIS/PACS server on iOS and Android based devices.


The purpose of any radiology mobile app is to share the reports and images and to perform complex radiology tasks with an easy interface on a range of mobile devices. The following criteria were used for comparison as most of the mobile RIS functionalities falls in one of this criteria.


This criteria discusses the functionalities specific to usability. It measures the easiness of interaction to perform an action on a mobile device when compared to that of a desktop pc.

Usability is more important and is a key efficiency factor when interacting with a complex system. For example adding annotations in image areas with hand writing or sketching. This enables the user to use this functionality instead of writing detailed descriptions in the report and can be quickly completed and easy to interpret by others.


This criteria discusses the functionalities that enable data sharing and workflows. Sharing is a key data quality factor. For example in radiology, patient reports and images are shared among the users as part of the workflow for documenting first or second opinion.


This criteria discusses the functionalities that can be accessed from various types of mobile platforms. Most of the vendors were having mobile apps specific to one or two mobile platform(s) I.e. IPhone and Android. Mobility may be possible indirectly with a mobile web browser for other platforms if RIS application is a web based.

The following is table listing the range of functionalities categorized by the above criteria that are possible in every mobile RIS/PACS app at minimum


No. Functionality Criteria

1. Search for patient with demographic details Usability
2. View Images from radiology server Sharing
3. View Reports from radiology server Sharing
4. Image activities (Zoom, Pan, Rotate etc.), annotation Usability
5. Report dictation with voice recognition Usability
6. Access from web, cloud, smart phones and tablets of various platforms Mobility
7. Search for patient history and reports Usability
8. Comparing with prior images/studies Usability
9. Upload images Usability, Sharing

Findings from comparison

  The following table shows range of functionalities available in the compared mobile apps categorised by criteria.

Criteria Kestral Karisma GE Centricity AccessNow I-MED
Mobility Available on iPhone, iPad, but not on android and windows phone. Web based system with limited features can be accessed from tablets. Available on Android and IPhone phones.

A Web based system. Accessed from any mobile web browser.

If accessed from web, dependent native functionality like sensors may not be possible.

Available on Android and IPhone apps, IPad, A web based system. Accessed from any mobile web browser in other platforms.

If accessed from web, dependent native functionality like sensors may not be possible.

Usability Simple to use, Minimum UI and features.

Notifications, Badge numbers, Report lists navigation

No image viewing

No search functionality, users work on only notified reports.

Dictation and Authorisation support.

Simple to operate, Minimum UI and features.

Search functionality with patient demographics. Supports imaging activities zoom, pan, scroll, W/L

No dictation support, split screen comparison with prior images, No Authorisation.

Simple to use, Minimum UI and features.

Search functionality with in the history of visits.

Image functions zoom, pan.

No dictation support or compare with prior images or reports, functionality, No authorisation.

Sharing Reports and Images shared between users, Workflows

Users can view and edit reports, dictate, and send voice files to server. Ability to authorise reports

Reports and images shared between users

No specific workflows

Users can view reports and images.

Reports and Images sharing.

Retrieve reports and images of referred patients.

Retrieve recent examination requests.

The following table shows range of functionalities available in the compared mobile without any categorisation.


Functionality Kestral karisma GE centricity AccessNow I-MED

Retrieve images from server No Yes Yes
Image functions( zoom ,pan, scroll) No Yes, supports zoom, pan, and scroll. Yes, supports zoom and pan only
2D/3D, MIPR capabilities No Yes No
Retrieve reports from server Yes Yes Yes
Retrieve tasks from server Yes, with the help of push notifications of reports to work No Yes, only examination requests
Workflow support Yes No No
Report dictation Yes No No
Search No functionality offered Yes, Search referred patients with demographic details Yes, Search only visited histories.
Comparison No comparison offered. Yes, comparison with prior images No comparison


In all the compared apps, it was observed that the minimum functionality implemented was reporting (with or without imaging).

Karisma notifications is a good usability feature which informs a user about the reports that requires user authorisation without opening the app and display badge numbers on top of mobile app icon. Without this, the user has to open the app, manual check for new reports and close the app. On opening app, reports that require authorisation are displayed in a list view and users can quickly open a report and edit and send back to radiology clinic. Users were able to dictate using mobile integrate voice system.

Karisma mobile supports work flow management from referral to report generation. The limitations are there was no support for images and search functionality in the mobile apps. Users need to work only the notified reports (work list) but a web based system available that can accessed from any web browser.

GE Centricity AccessNow has some good usability features around images. Users can view images with 2D, 3D, MIP/MPR capabilities and perform image related functions like zoom, pan, scroll etc. The most interesting feature was split screen comparison with prior images. It helps users a lot in decision making. The other feature is search functionality with patient demographics (Patient Id, name, access number, modality, date range). Everyone who has access to this mobile app can search for any patient and not sure how the privacy concerns were addressed.

I-Med radiology app has some good usability features similar to that of GE Centricity AccessNow app. Users can view images without 2D/3D but can perform image functions zoom and pan. It has different view styles (screen orientation, resolution) in iPad when compared on iPhone. It’s a good usability feature of adjusting to surroundings (responsive design). Users can search their visit history, retrieve referred reports and access recent examination requests.

Karisma mobile app adopts task based approach with modalities. It enables the users to perform pre allocated tasks only and a search for referral patient is not possible. However, GE centricity Accessnow and I-Med adopts query based approaches. It includes querying the patient information and reports with image analysis.

There’s a scope for providing more functionality and improvement in these mobile apps as outlined below.

Karisma GE Centricity AccessNow I-Med
Imaging functionality

Retrieve, Zoom, Pan.

Search functionality patient and reports


Workflow based approach.

Modalities(Work lists), Dictation

Work flow


Search functionality,



All the compared mobile apps were not close to each other in terms of functionalities and their functionalities were dependent on the vendor and were restricted to specific needs. There were no specific design guidelines that specifies what a RIS mobile app is and what features it should contain at minimum. The range of functionality varied from vendor to vendor. Some vendors implemented workflows and others implemented image related extra activities such as panning, zooming etc. However most of the vendors developed apps for IOS and Android platforms only but not for Windows phone.

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

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.

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


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 (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

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.

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.