National ehealth transition authority and secure messaging 6 may 2009
This presentation is the property of its rightful owner.
Sponsored Links
1 / 31

National eHealth Transition Authority and secure messaging 6 May 2009 PowerPoint PPT Presentation


  • 60 Views
  • Uploaded on
  • Presentation posted in: General

National eHealth Transition Authority and secure messaging 6 May 2009. Where are we going?. Semantic interoperability: Level 1: no interoperability at all Level 2: technical and syntactical interoperability (no semantic interoperability)

Download Presentation

National eHealth Transition Authority and secure messaging 6 May 2009

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


National ehealth transition authority and secure messaging 6 may 2009

National eHealth Transition Authority and secure messaging6 May 2009


Where are we going

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


Where are we going1

Where are we going?


Where are we going2

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?


Interoperability

Interoperability

  • “not so much to machines working together as to human beings understanding each other”

    • IEEE, 2005


Messaging what have we got now

Messaging: What have we got now?

Store and forward

Time

Sender

Send

Receive

Message server

Send

Receive

Receiver


Messaging what have we got now1

Messaging: What have we got now?

Store and forward

Time

Sender

Receive

Send

Message server

Receive

Send

Receiver


Messaging what have we got now2

Messaging: What have we got now?

Point to point

Sender

Receiver


Messaging what have we got now3

Messaging: What have we got now?

Point to point

Receiver

Sender


What we need

#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)


What we need1

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


Web services

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


Web services1

Web services

http://www


Web services2

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>


Web services3

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


Web services4

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


Web services5

Web services

  • NeHTA’s vision:

    • No middle-man


National ehealth transition authority and secure messaging 6 may 2009

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.


The challenge

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


  • E health pip

    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


    How do the products stack up

    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.


    So what do we do

    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.


    Nehta s security requirements

    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;


    Nehta s security requirements1

    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.


    Assessment approach

    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


    Assessment criteria questions

    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)


    Assessment principles

    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)


    Assessment principles1

    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


    Assessment principles2

    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


    Assessment principles3

    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?


    Assessment principles4

    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


  • Login