NHS eProcurement strategy published in April 2014 sought to establish the global GS1 coding and PEPPOL messaging standards throughout the healthcare sector and its supporting supply chains.
What is GS1 ?
GS1 is the international not-for-profit organisation behind the only global system for bar coding, and for standardised identification of products, assets, services, places and organizations.
To start off NHS wants to implement GS1 for for person identification (using bar coded wristbands) product coding (using manufacturers barcodes on products), location coding (by allowing trusts to define their locations as per agreed format)and data synchronisation. This linking of patient, product and location initially will create improvements for traceability in Patient's pathway. They can identify where they’ve been, who treated them, what products were used, which products were implanted, which equipment they used, the drugs they took, where they were located
In future it is planned to use GS1 barcodes for events medical records and equipment as well for end to end traceability using standard well defined coding mechanism.
What is PEPPOL ?
PEPPOL stands for Pan-European Public Procurement Online and was designed to solve interoperability issues for electronic procurement
To start off NHS want to implement PEPPOL for eOrdering, eInvoicing, electronic Credit Notes and Advance Shipping Notifications. PEPPOL implementation would modify the traditional way of each trust needing an individual EDI connection to each of their suppliers, large and small. But PEPPOL through a nationally established infrastrucure will allow a trust to have one single eProcurement link to the outside world, via which they can trade with current future suppliers, large and small, in the UK as well as internationally. A supplier also needs only one connection to PEPPOL, in order to reach not only all NHS customers, but also all other PEPPOL-connected trading partners at home and abroad.
Where are we now ?
DH has provided central funding in order to develop GS1 standards within 6 acute trusts which are to act as demonstrator sites for the remainder of the NHS. The demonstrator sites have 2 years starting January 2016 to roll out the GS1 and PEPPOL standards.
Relevance of PEPPOL in Post-Brexit world
PEPPOL has no dependency on being in EU or not. PEPPOL standardizes the way suppliers and organisational buyers interact with each other. PEPPOL through locally provided infrastructure will enable e-trading driving down costs and suppliers, who trade across Europe.The average costs associated with processing a single order through to invoice at NHS trusts range from £5 to £7. Business cases produced by demonstrator sites are expected to demonstrate that that cost can be reduced to around £1.
The country which uses PEPPOL most widely is Norway which is not even in EU. The Norwegian public sector has chosen to communicate through the PEPPOL network and in 2015, approximately 21 million electronic invoices were exchanged via PEPPOL Norway bringing decent savings and improved traceability of public expenses.
Thursday, 3 March 2011
The one thing that is missed quite often during deployment and rollout of HL7 (read HL7V2.x) is the “clinical safety” factor. It is not often considered if introducing the messaging is any way compromising the information quality of patient’s data or if it’s introducing any major business changes to the existing clinical workflow in the organisation. Organisations need to stress to the system providers as well as to the system integrators that they ought to consider clinical safety as a major factor in all stages of the rollout including development, deployment and testing.
There are ways to ensure that the introduction of HL7 does not compromise clinical safety. This post discusses a approach for this
Conformance Accreditor: The organisation needs to employ a system integrator or act itself as one (in case it has a internal tech team) to define conformance standards
Conformance Guidelines: The defining of conformance standards need to be based on the following principles
2. Avoiding optionality and being more specific when defining the messages
3. Identify the use cases and build story boards using every day scenarios of the organisation. Involve the organisations clinical and administrative team in this.
4. Publication of defined code set to be used in the messages
5. Define mapping guidelines to enable system providers to identify the correct data attributes
6. Provide sufficient guidance on message interactions for the messages that need to be sent and received by the systems for different events.
7. Define the expected systems behaviour while processing the message.
The publication of proper definition of code sets and values, message specifications and mapping guidelines ensures that data is not manipulated in a clinically unsafe fashion or mapped to the wrong code compromising patient safety.
(See this for a better understanding of conformance : http://secure.cihi.ca/cihiweb/en/downloads/hl7can_conformance.pdf)
Conformance Tools: Provide simple test harness tools adhering to the proposed conformance standards, for the system providers to check the correctness of their implementation- e.g. message structures, data types, expected code values. Provide ability to view data in the message in a GUI so that they do not have to traverse the message. These tools are expected to be provided by the system integrator
Conformance Testing: The clinical safety testing process involves exhaustive end to end testing to see if the data sent by the sending systems has not hindered the work flow in the receiving system. The testing to defined work flows in system where the data is received and used ensures that safety of the patients is not compromised
Defining Transition: The changes that are brought about by implementing HL7 in an organisation needs to be formally documented. The capabilities and workflows in the organisation that are impacted by the implementation needs to be compared and ensure that the users are aware of the changes through training.