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.

General

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

Restrictions

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.

where

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.

Examples

Version 2

<SB>
MSH|^~\&|ZIS|1^AHospital|||200405141144||ADT^A01|20041104082400|P|2.3|||
AL|NE|||8859/15|<CR>EVN|A01|20041104082400.0000+0100|20041104082400<CR>
PID||""|10||Vries^Danny^D.^^de||19951202|M|||Rembrandlaan^7^Leiden^^7301TH^""
^^P||""|""||""|||||||""|""<CR>PV1||I|3w^301^""^01|S|||100^van den Berg^^A.S.
^^""^dr|""||9||||H||||20041104082400.0000+0100<CR>
<EB><CR>

Version 3

<SB>
<?xml version="1.0" encoding="ISO-8859-15"?>
	<MFMT_IN10001NL xmlns="urn:hl7-org:v3" xmlns:voc="urn:hl7-org:v3/voc" 
	         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<id extension="10213" root="2.16.840.1.113883.2.4.99.1.700222.1"/>
	<creationTime value="20050216140000"/>
	<versionId>V3ED2005</versionId>
	<interactionId extension="MFMT_IN100010NL" root="2.16.840.1.113883"/>
	<processingCode code="P"/>
	. . .
	. . .
	</MFMT_IN10001NL>
<EB><CR>

Acknowledgement

<SB><ACK><EB><CR>

Negative Acknowledgement

<SB><NAK><EB><CR>

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

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.

Individuals

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.

Individual providers uses the above devices

1) To access patient e-health record from PCEHR

2) To access information from NASH directory

Organisations

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.

IMPACT ON HEALTH SERVICES

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.

Patients

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.

Providers

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