1. National eHealth Transition Authority and secure messaging 6 May 2009

2. Where are we going? Semantic interoperability: –Level 1: no interoperability at all –Level 2: technical and syntactical interoperability (no semantic interoperability) –Level 3: two independent levels of partial semantic interoperability of meaningful fragments Level 3a: unidirectional semantic interoperability Level 3b: bidirectional semantic interoperability –Level 4: full semantic interoperability, sharable context, seamless co- operability

3. Where are we going?

4. Full semantic interoperability is a “lengthy, expensive and possibly unattainable goal” “Semantic Interoperability for Betther Health and Safer Healthcare”, Research and development roadmap for Europe - SemanticHEALTH Report Jan 2009

5. Interoperability “not so much to machines working together as to human beings understanding each other” –IEEE, 2005

6. Messaging: What have we got now? Store and forward Time Sender Message server Receiver Send Receive

7. Messaging: What have we got now? Store and forward Time Sender Message server Receiver Receive Send

8. Messaging: What have we got now? Point to point Sender Receiver

9. Messaging: What have we got now? Point to point Receiver Sender

10. What we need A directory Method of data transfer Method to “advertise” functions (e.g. get path report, receive referral, update details etc) #611 #581 #938 patientprovideragency

11. What we need Method to protect data and prove identity Standard clinical terminology –What does “cold” mean? –99 ways to say “room air” –126 ways to say “high blood pressure” Standard data structure PKI HL7 SNOMED CT

12. Web services Includes XML TCP (communication rules)Domain Name SystemRouters (traffic controllers) communication structure of the internet SMTP (eMail)HTTP (world wide web)and others protocols that run on the internet Web services

13. http://www

14. Web services <SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"> 41546836 </SOAP-ENV:Envelope <SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"> Royal Eye & Ear Response Request

15. Web services Service Registry NeHTA developed and maintained Service Requester e.g. GP Service Provider e.g. Hospital Service Description Service Find Connect Publish Examples of services: Search Update a record Send path results Receive referral

16. Web services Service Registry NeHTA developed and maintained Service Requester e.g. GP Service Provider e.g. Hospital Service Description Service Find Connect Publish GPHospital Examples of services: Search Update a record Send path results Receive referral

17. Web services NeHTA’s vision: –No middle-man

18. PKI Not a technology so much as a methodology. There is no other way of: –Proving identity AND –Guaranteeing the integrity and provenance of a message.

19. The challenge Tony Abbott, 2003: 5 years from now we’ll have a shared electronic health record “In some ways this problem represents a standard chicken- and-egg dilemma—it is hard to understand the need to be enabled to utilise Web services when there are few existing services to consume and conversely there is no market to develop web services when there are few consumers enabled.” -NeHTA, Towards a secure messaging environment, 2006 Hence….

20. e-Health PIP Peter Flemming (new NeHTA CEO): “2009 is the year of delivery” –Significant pilots: discharge referral medication management –Recent announcement Consensus statement (b/ween Pathology peak bodies and NeHTA) e-Health PIP: incentivising as a driver for change

21. How do the products stack up? Web servicesPKIPKI signature ArgusMessenger AllTalk Division Report HealthLink Medical Objects ReferralNet How the main GP secure messaging products currently align with the direction implied by the e-Health PIP. The greyed-out ticks indicates the understanding that this work is mature but not yet released in the product. Information sourced by a variety of means, and is an indicator only. The situation could change at any time and a serious assessment requires confirmation with vendors.

22. So, what do we do? Look for: –Web services. –Digital signing with PKI. –Directory integration. –Usability Ease of install. Ease of use. Ease of maintenance/monitoring. –Integration A service using web services that communicates with another. –Hospital direction. –Discuss options with division and SBO colleagues.

23. NeHTA’s security requirements Identification: –Provide the ability to physically and electronically identify the party through descriptions, names, keys and validation details; Authentication: –Enable the identification of an entity; Confidentiality: –Ensure the privacy of the information within the message by preventing disclosure to unauthorised parties and ; Integrity: –Ensure that the information is not altered by unauthorised entities in a way that is not detectable by authorised entities;

24. NeHTA’s security requirements Non-repudiation of Origin: –Ensure that the sender of a message cannot deny they were the originator/sender of that message and that it has not been sent; Non-repudiation of Receipt: –Ensure that the receiver of a message cannot deny receipt of that message; Access Control: –Provide the ability to grant privileges to information, systems or resources; Audit / Logging: –Support the monitoring and logging of message interaction to aid fault detection and prevent misuse; and Privacy: –Control or influence the handling of data about an individual.

25. Assessment Approach Ascertain all products Ascertain all products Basic assessment Detailed assessment Detailed assessment Demo Assessment Fitness for Purpose and Ranking OUTCOME Assessment Principles 1.Meet open standards 2.Be accepted in the market place 3.Have future capacity 4.Be scalable/transferable 5.Provide an architectural foundation 6.Support technical requirements 7.Sustainable business model 8.Acceptable support model 9.Cost effective 10.Leverage existing investments 11.Transparency to users 12.Provision of value added service ENVIRONMENTAL ASSESSMENT ENVIRONMENTAL ASSESSMENT State Projects GP Readiness Specialist Readiness PRODUCT ASSESSMENTS Contract negotiation Application tailoring Implementation planning

26. Assessment criteria & questions Meet Open Standards criteria –providing a level playing field for conformant interoperability without vendor prejudice; How do you meet the NeHTA Standards: - interoperability, security, web services(find more)? How does your product use HL7? How does your software address the private transmission/receipt of patient data? How does your product manage a provider directory? Be accepted in the market place –solutions exist or can be readily created around the standards; What is your experience in the Health industry (Referees – divisions/GPs)

27. Assessment principles Have future capacity –be able to grow with emerging standards to support new capabilities; How will your product be able to grow with emerging standards to support new capabilities? Be scalable –for a broad range of technical capabilities from sole providers to large institutions; Can you provide examples of your product working in similar environments to our environment Can you provide examples of a broader GP/Allied health electronic communication application (ie GP-aged care, GP-Hospital, GP-Pharmacy)

28. Assessment principles Support technical requirements –delivering sufficient technical capability to meet secure messaging requirements. Can you provide detailed specifications? Sustainable business model –does the vendor have an appropriate and scalable business model to give confidence of future viability Sustainable business relationship Governance structures Ongoing viability

29. Assessment principles Acceptable support model –does the vendor provide a support model that meets the needs of the users; What support (helpdesks) can you provide this group during the installation of the product What ongoing user support do you provide Cost effective –is the solution cost effective for users & divisions; What is your costing model? Please address the areas of: –Licence –installation –maintenance (including patches) –upgrades –ongoing support –Training

30. Assessment principles Leverage existing investments –does the solution build on existing investments in infrastructure and standards; Transparency to users –is the solution transparent to the end user – or at least minimise the impact on the users; Which clinical and messaging systems is your product compatible with? Please discuss your products relationship with these products. How does your product interact with non-clinical systems such as Microsoft Word?

31. Assessment principles Provision of value-add services –does the solution provide additional services that deliver added value or improvement for users and their business processes; Does your product/company provide additional products/services other than those outlined above within the Health environment