National eHealth Transition Authority and secure messaging 6 May 2009

1. National eHealth Transition Authority and secure messaging6 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 Where are we going?

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 Send Receive Message server Send Receive Receiver

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

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. #581 #611 #938 patient provider agency What we need • A directory • Method of data transfer • Method to “advertise” functions (e.g. get path report, receive referral, update details etc)

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 SNOMED CT HL7

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

13. Web services http://www

14. Web services Request <?xml version="1.0"?> <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"> <SOAP-ENV:Body> <m:getProviderName xmlns:m="http://soapware.org/"> <param1 xsi:type="xsd:int">41546836</param1> </m:getProviderName> </SOAP-ENV:Body> </SOAP-ENV:Envelope Response <?xml version="1.0"?> <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"> <SOAP-ENV:Body> <getProviderNameResponse> <Result xsi:type="xsd:string">Royal Eye & Ear</Result> </getProviderNameResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

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

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

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? 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 ENVIRONMENTAL ASSESSMENT OUTCOME PRODUCT ASSESSMENTS Ascertain all products Basic assessment Detailed assessment Demo Assessment Fitness for Purpose and Ranking Contract negotiation State Projects Application tailoring GP Readiness Assessment Principles Meet open standards Be accepted in the market place Have future capacity Be scalable/transferable Provide an architectural foundation Support technical requirements Sustainable business model Acceptable support model Cost effective Leverage existing investments Transparency to users Provision of value added service Implementation planning Specialist Readiness

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