CONNECT Solution and Core Services Overview

Transcript CONNECT Solution and Core Services Overview

CONNECT Solution and Core Services Overview

CONNECT Solution

David Riley

How the Federal Effort was Started

•

Upon release of NHIN trial implementations RFP, Feds were energized to determine how to connect to the emerging NHIN

•

FHA governance chartered the “Connect” initiative to define a strategy, plan and requirements for connecting to the emerging NHIN

•

Six principles guided the development of the strategy

–

Inclusivity

–

Collaboration

–

Proactivity

–

Incrementalism

–

Reuse

–

Continuity

Federal Strategy for CONNECTing to the NHIN

Establish the Federal NHIN Consortium

A cross agency FHA collaboration to create solutions for health exchanges in and out of government

Participate in the Trial Implementations

Articulating Federal NHIN-C Consortium role in the NHIN Trial Implementations Cooperative

Develop a NHIN Gateway Solution

Establish a Federal NHIE Solution (“NHIE-Fed”)

Approach Bottom up approach Services abstracted so support the information exchanges of multiple AHIC Use Cases.

Inter-NHIE information exchange focused

NHIN Principles

The Network Principle The Trust Principle The Local Autonomy Principle

NHIN Architecture

Craig Miller

The NHIN: Beyond Enterprise Boundaries

What is a health enterprise?

– A common patient identifier – Indexes of patients and health records – Existing trust relationships – A common security domain – Common standards

The NHIN is needed when information exchanges

take place beyond enterprise boundaries

A Unified Platform for Innovation

Most important architectural decision made by the NHIN:

Provide a unified platform for information exchange

• Single transport (Web Services over HTTP) • Single security model (Public Key Infrastructure)

A single platform provides the basis for

Architectural Attributes of the NHIN

Minimal Conformant Open Unified Platform Secure

Adaptable Trustworthy Scalable

An Open Architecture

• All of the specifications in the NHIN are based on open standards that are freely available and implemented by a wide range of industry vendors • The NHIN does not require a proprietary network and can operate on the public Internet (though it is not limited to this) • All of the NHIN specifications are platform independent, and are capable of being implemented using: – Multiple operating systems (Windows, Solaris, Linux, etc) – Multiple programming languages and frameworks (Java, Microsoft .NET, etc) 11 Copyright 2009. All Rights Reserved.

A Minimal Architecture

Shared

PKI Certificate authority Organizational registry Network identifier distribution Legal framework (DURSA)

Local

A Conformant Architecture

•

The NHIN builds on the work of existing standardization efforts wherever possible

– HITSP – IHE – HL7 – OASIS – Others •

Particular focus this year on harmonizing NHIN specifications for patient discovery and document exchange with existing and planned IHE work

A Secure Architecture

The NHIN has been designed from its inception to provide secure information exchanges through:

A Trustworthy Architecture

The NHIN provides important safeguards to engender trust in information exchanges beyond organizational boundaries:

–

Authorization

– requestors of medical information must provide authentication and a purpose for use –

Consumer control

– patients have the ability to articulate their preferences for the sharing of identifiable medical data –

Auditing

A Scalable Architecture

The NHIN is architecting capabilities into the network today that will be required to support large-scale production usage in the future:

– Ability to secure messages that are transmitted through intermediaries or network service providers – Reliable message delivery in high throughput environments – Dynamic discovery of organizations participating within the network

An Adaptable Architecture

The NHIN will need to meet information exchange requirements tomorrow that cannot be completely understood today, which requires a flexible architecture that provides:

– The ability to be implemented at any jurisdictional scale (local, state, regional, national, international) – Support for different patterns of information exchange (request/retrieve, publish/subscribe) – The ability to define specialized profiles that define NHIN capabilities for individual healthcare domains such as quality reporting, biosurveillance and beyond 17 Copyright 2009. All Rights Reserved.

NHIN Services Architecture

NHIN Profiles Consumer Preferences Profile

Store and exchange consumer preferences for sharing of personal health information

Other Profiles in Development

GIPSE (Biosurveillance)

Profiles

describe how to implement services for a specific domain like consumer preferences for information sharing or biosurveillance

Discovery Services

•Subject Discovery •Authorized Case Follow-up •Query for Documents •NHIE Service Registry

NHIN Services Information Exchange Services

•Retrieve Documents •Query Audit Log •Health Information Event Messaging

Services

describe specific interfaces (web services) used between HIEs to discover and exchange health-related information

Messaging, Security and Privacy Foundation Messaging

•Message Transport •Services Definition

Security

•Public Key Infrastructure •Encryption •Digital Signature

Authorization Framework

• Requestor Authentication • Requestor Authorization

Messaging, Security and Privacy Foundation

Looking Beyond

•

Integration with specialty health networks

– – – Pharmacy Claims and administration Clinical research •

Using SOA to enable value-added network services

– Clinical decision support – Terminology services •

Moving beyond exchanges of static documents to an event-based mesh of linked, dynamic data

NHIN Specifications

Christopher Brancato

“Defining the NHIN Dial Tone in 2009”

Interface Specification References Standard Description Messaging, Security and Privacy Foundation

Messaging Platform Authorization Framework

NHIN Services

SOAP/WSDL/ WS Addressing/WS Security SAML Provide secure messaging services for all communications between NHIN-enabled health organizations Articulate the justification for requesting patient medical information Subject Discovery PIXv3 Query for Documents Retrieve Documents Query Audit Log Authorized Case Followup XCA XCA IHE ATNA PIXv3 Services for locating patients based on demographic information Locate health documents associated with a specific patient that conform to a set of query criteria Retrieve specific requested documents associated with a patient Log requests for patient health information and make this log available to patients Provide an ability to re-identify pseudonymized patient records when legally permitted for public health case investigations Health Information Event Messaging NHIE Service Registry WS BaseNotification UDDI Provide a publish/subscribe capability for ongoing feeds of data between NHIN enabled health organizations Registry servers that enables NHIN-enabled health organizations to discover the existence and connection information for other NHIN-enabled health organizations

NHIN Profiles

Health Information Event Messaging & Profile Development

Brian E. Dixon, MPA Health IT Project Manager Regenstrief Institute, Inc.

Health Information Event Messaging in the NHIN

HIEM Interaction Diagram NHIE 1 “Subscriber” NHIE 2 “Notifier” Hospital A “Publisher”

NHIE Gateway Subscribe NHIE Gateway NHIE Gateway Notify NHIE Gateway Publish EHR Systems

HIEM provides a "publish and subscribe" mechanism to enable ongoing exchange of updateable health information between NHIEs

Applications of HIEM in the NHIN

The goals of HIEM include support for

– Data sent on a recurring basis to multiple stakeholders • Quality Reporting, Population Health Reporting, Resource Utilization – Documents that may be updated or changed over time • Consumer Preferences, Advanced Directives

Utilized at the December 2008 NHIN Demonstrations Uses WS-BaseNotification specification

A General Framework for HIEM

Work is under way to review the current HIEM specification and recommend necessary changes

Ensure compatibility with a range of document types Enable efficient process for defining future topics or profiles

Discussions are focused on population health and consumer preferences use cases as first profiles Guidance from FHA, ONC, HIEs, and CDC are directing our work, which will conclude in September 2009

Privacy & Identity Management

Richard Franck

NHIN Authorization Framework

The NHIN Authorization Framework extends the NHIN Messaging Platform specification to describe how Secure Access Markup Language (SAML) is used to carry information about the requester on all NHIN transactions.

•

SAML Assertions

– User ID of the requester. (Note: there is no assumption that a User ID from the initiating HIE is known in the responding HIE.) – User Role, specified using a coded value from SNOMED CT, from a list defined in the specification.

– Purpose for Use, specified using a coded value from a list defined in the specification – User Name and Organization Name, in free text, for audit purposes •

These assertions are digitally signed as described by WS-I Security Profile and the NHIN Messaging Platform specification

NHIN Authorization Framework

Potential changes to the NHIN Authorization Framework identified by the Specification Factory:

•

Define a structured way to represent the organization from whom the request originates

– The HIE (or “node” on the NHIN) – The care provider organization or other organization representing authorized users on the NHIN – Many HIEs use “organization” as a factor in access consent policies •

Limit the variation in user ID format allowed by SAML

– There may not be a need for full distributed/federated user ID management, but simplifying the user ID format will facilitate use of common identities on a limited scale

These potential changes are prioritized behind updates to the Consumer Preferences Profile and may be completed after September, 2009.

Consumer Preferences Profile

The NHIN Consumer Preferences Profile describes the format of an Access Consent Policy that can be shared among HIEs, and describes how the Health Information Event Messaging specification can be used to exchange these Policies.

• An Access Consent Policy is a structured representation of

who

may access

what information

for

what purpose

what times

• The representation utilizes the eXtended Access Control Markup Language (XACML) to describe a policy, with a combination of attributes defined by XACML and defined by the Consumer Preferences Profile.

Consumer Preferences Profile

Attributes defined by the Consumer Preferences Profile:

Despite the name “Consumer Preferences Profile,” the specification describes how to represent policies that may be created by other actors, including health care providers and HIEs themselves.

Consumer Preferences Profile: Issues and Updates

Standardize definition of attributes with work going on in OASIS Cross-Enterprise Security and Privacy Authorization (XSPA), XACML, and SAML technical committees.

– The OASIS work effort was initiated during the Trial Implementations, and covers somewhat different scope, but we are hopeful that the profiles being developed by OASIS can be modified to accommodate NHIN requirements – This work item may involve work in the HL7 Security technical committee to update the HL7 RBAC “Object Definitions” catalog, which is referenced by the OASIS profile.

When the OASIS work is complete, the Consumer Preferences Profile will be modified to refer to the attributes defined by OASIS, and eliminate “custom” attributes defined by NHIN.

Consumer Preferences Profile: Issues and Updates

– – –

Revisit the question of how and when to exchange Access Consent Policies between HIEs

The current specification calls for a publish-subscribe model to notify HIEs with patients in common. Policies are retrieved as documents using the “Retrieve Document” transaction.

HITSP TP30 describe the use of Query for Documents transaction to query for Access Consent Policies, but does not describe the situation under which an HIE would issue a query. Need to consider the SSA requirements, where the Access Consent Policy needs to grant permission for the Subject Discovery transaction to proceed – precluding an exchange based on the knowledge of patients in common.

Establish consensus on desired solution; work with HITSP to determine if TP30 should be updated; Update Consumer Preferences Profile to conform to TP30.

Consumer Preferences Profile: Issues and Updates

Publish a White Paper to define certain key concepts that permeate the Access Consent Policy domain for Health Information Exchange, and identify areas for future standardization.

– – What does it mean to “opt-in” or “opt-out” of the NHIN?

What are an HIEs responsibilities regarding the re-disclosure of data it receives over the NHIN?

Work in the Information Services sub-team to update the specifications for Document Metadata to support the metadata elements required to provide effective Access Control.

Security

Erik Rolf

Agenda

Project Scope and Goals Privacy and Security in the NHIN Parallel Work Threat Analysis Future Work

Background and Scope

• NHIN Trial Implementation work began in October of 2007.

• Privacy and Security were and are tasked as key focus areas.

• Privacy context was defined based on NHIN guiding principles. • Threat and vulnerability analysis was conducted on the Core Services specifications.

Parallel Work

NHIN Cooperative Technical and Security Core Services Work Group Federal Security Strategy for Health Information Exchange AHIC Confidentiality, Security and Privacy Work Group Certification Commission for Health IT (CCHIT) Health Information Technology Standards Panel (HITSP) Health Information Security and Privacy Collaboration (HISPC) National Institute of Standards and Technology (NIST) Standards Development Organizations

Defines functional and technical specifications for key services to be used in implementing health information exchanges.

Develops guidance that enables the adoption of secure, scalable health information exchanges among Federal and private sector healthcare organizations.

Makes recommendations on the protection of personal health information in order to secure trust, and support appropriate interoperable electronic health information exchange.

Private-sector collaboration launched by AHIMA, HIMSS, and the National Alliance to certify health IT products.

Public-private partnership chartered to identify, recommend, and harmonize data and technical standards for healthcare.

Federal and state partnership working to harmonize laws and policies related to security and privacy.

Develops federal security standards, guidelines, and procedures under authority from FISMA.

Broad range of consortia, associations, and other bodies that create and maintain individual technical and data standards.

Privacy Context

The NHIN is comprised of:

– – – – Covered Entities (HIPAA) Business Associates of Covered Entities (HIPAA) Governmental agencies subject to varying privacy laws HIPAA non-Covered Entities subject to other privacy laws

The NHIN is an organizing concept, and therefore is not in and of itself subject to privacy laws Participant privacy compliance is mandated through the governing body and the Data Use and Reciprocal Support Agreement (DURSA)

Current Privacy Landscape of the NHIN

•

Participating NHIEs play an important role in protecting privacy by:

– Obtaining authorization to share data across the NHIN – Authenticating participant users – Enforcing participant access for permitted purposes •

The NHIN Trial Implementations focused on developing and implementing technology that supports core privacy principles

Status of the NHIN Security & Privacy Protections

Messaging Platform

Supports data Confidentiality and Integrity

Audit Log Query Interface

Supports accounting of disclosures

Authorization Framework Interface

Supports authorization for access, purpose requests and verification of user

Status of the NHIN Security & Privacy Protections

Consumer Preferences Interface

Supports restrictions on access

Authorized Case Follow-Up

Supports requests for de-identified data and case follow-up

DURSA

Important component of the trust fabric: Establishes obligations of all parties to employ appropriate safeguards for data protection and to abide by code of conduct

The threats expected in the interoperability environment closely model those of web services and web service constructs. NHIN is closely correlated with web service mitigation strategies and mechanisms to address existing and emergent threats.

Web Services Threat Matrix

2009 Security Work

2009 Security Efforts Focus on underlying protocols and capabilities needed to further secure messages between NHIN Participants:

X.509 Digital Certificate Revocation 2.

End to End Security 3.

Security: Certificate Revocation

What is it?

Why do we need it?

Who needs it?

Why haven’t we done it already?

What specifications is it based on?

What is the impact?

What are the risks?

Mechanism to ensure that digital certificates provided with requests for medical information are in fact still valid As the NHIN governance evolves, it may be necessary to revoke the digital certificates of organizations no longer authorized to participate in the NHIN Everyone NHIN governance mechanisms and production certificate authority not in place in 2008 Online Certificate Status Protocol (OCSP) NHIE gateways will need to implement an OCSP client to check the status of certificates with incoming messages Determine frequency of revocation checking and caching; ensure selected NHIN CA provides OCSP servers

Status/Schedule

Security: End to End Security

What is it?

Why do we need it?

Who needs it?

Why haven’t we done it already?

What specifications is it based on?

Mechanism to encrypt sensitive message content from the point of origination to point of destination (e.g. from one clinician’s computer to another) NHIN only supports point-to-point transport-level encryption today (from NHIE gateway to NHIE gateway). End-to-end encryption is important when messages pass through intermediaries before reaching their destination, or when there are concerns about intra-enterprise security of data Those requiring encryption of messages across gateways. Likely an optional capability for some NHIEs who require it Considered too complex given the limited time available in 2008; NHIN at present is a flat peer-to-peer model with no intermediaries XML Encryption

What is the impact?

What are the risks?

Status/Schedule

Implementing organizations would require a PKI infrastructure (e.g. certificates ) at the end user level, not just the gateway level Need to determine which parts of message should be encrypted, while leaving enough information in plaintext to facilitate routing Deliberations Started; Targeted September Delivery 46 Copyright 2009. All Rights Reserved.

Security: Federated Trust

What is it?

Why do we need it?

Who need it?

Why haven’t we done it already?

What specifications is it based on?

What is the impact?

What are the risks?

Status/Schedule

Mechanism for the NHIEs to trust certificate authorities beyond the one established by the NHIN Related to end to end security (see previous slide); while the NHIN may issue certificates for gateways, it is likely that NHIEs or other organizations will issue certificates for individual users Those requiring end to end security who have already established CAs End to end security not established in 2008 WS-Federation NHIN governance would need to determine which certificate authorities to trust Priority of this capability is based on expected growth/evolution of the NHIN Deliberations Started; Targeted September Delivery 47 Copyright 2009. All Rights Reserved.

Ongoing Work

• Stay abreast of security dependencies and processes of NHIN participants • Collaborate with HITSP, IHE and HL7 on interoperability standards • Collaboration with parallel workgroups regarding privacy and security implementation guidance • Continued security control evaluation to defend against continually evolving threat landscape

Information Services

Karen Witting

Subject Discovery – Purpose

The first step in the three-step process of retrieving data from another NHIE:

Subject Discovery

Query for Documents Retrieve Documents

NHIE 1 Patient Registry Record Added PRPA_IN201301UV NHIE 2

Subject Discovery – Cases

Three Subject Discovery Cases Demonstrated at 2008 NHIN Forum

1. Subject Query:

No Match

2. Subject Query:

Unambiguous Match

3. Subject Query Return:

Unambiguous Match

Subject Discovery – Approach

NHIE 1 Mary Smith 123/NHIE1 Patient Registry Record Added PRPA_IN201301UV02 Acknowledgement Patient Registry Record Added PRPA_IN201301UV02 Patient Registry Record Revised PRPA_IN201302UV02 Acknowledgement Acknowledgement NHIE 2 NHIE 3 Mary Smith 678/NHIE3 • •

No dependence on a central NHIN MPI No specific requirement for MPI within an NHIE

Subject Discovery – Notes

Trigger Events could be

– Clinician attempting to locate a patient in another NHIE (i.e. ad hoc) – Arrival of a new patient in an NHIE

Subjects could be

Subject Discovery – Standards

Patient Registry Record Added

(PRPA_IN201301UV02)

Patient Registry Record Revised

(PRPA_IN201302UV02)

Patient Registry Record Nullified

(PRPA_IN201303UV02)

Patient Registry Duplicates Resolved

Future of Subject Discovery

•

Adoption of new IHE profile XCPD

– Cross-Community Patient Discovery – HL7 Patient Registry Query by Demographics (PRPA_MT201306UV02) – Modeled after IHE Patient Demographics Query transaction with slight adjustments for different environment and purpose •

Information Services subgroup plans to review XCPD with respect to the needs of the NHIN and adopt as appropriate

Query for Documents – Purpose

The first step in the three-step process of retrieving data from another NHIE:

Subject Discovery

Query for Documents

Retrieve Documents

Initiating Community

Registry Stored Query [ITI-18] Document Consumer Retrieve Document Set [ITI-43] Initiating Gateway Cross Gateway Query [ITI-38] Cross Gateway Retrieve [ITI-39]

Responding Community

Query for Documents – Approach

•

Based on IHE’s XCA profile

•

Retrieves document metadata held by another NHIE (or community, in the language of the IHE specifications)

– Response will include a globally unique id called the homeCommunityId •

An NHIE may be:

– An IHE XDS Affinity Domain that defines document sharing using the XDS profile – -- OR - Another type of community with a different internal sharing structure

Query for Documents – Standards

•

IHE XCA

– HITSP/TP13 20071106 V2.1.1 - Manage Sharing of Documents – There are constraints to the list of operations on the interface as defined by IHE XCA Cross Gateway Query transaction •

ISO 15000-4 – ebRS - Registry Stored Query

Query for Documents – Criteria

 Document Entry Patient Id  Document Entry Class Code  Document Entry Class Code Scheme  Document Entry Practice Setting Code  Document Entry Practice Setting Code Scheme  Document Entry Creation Time From  Document Entry Creation Time To  Document Entry Service Start Time From  Document Entry Service Start Time To  Document Entry Service Stop Time From 59 Copyright 2009. All Rights Reserved.

 Document Entry Service Stop Time To  Document Entry Healthcare Facility Type Code  Document Entry Healthcare Facility Type Code Scheme  Document Entry Event Code List  Document Entry Event Code List Scheme  Document Entry Confidentiality Code  Document Entry Confidentiality Code Scheme  Document Entry Format Code  Document Entry Status

Query for Documents – Notes

• The response to this query is a collection of document ids referring to available documents, and some metadata describing each • Document references may be used in the Retrieve Document transaction • Document references are valid for a limited duration (the timeframe of which is determined by the implementation of a particular NHIE), or, if the document reference is ever the subject of a successful Retrieve Document transaction, it will persist forever

Query for Documents – Future

•

XCA consistency issues – agreed:

– Expand to include greater functionality by using all types of queries specified by XCA – Expand to support asynchronous process: required on responding gateway, optional on initiating gateway •

XCA consistency issues – in progress:

– Review work in IHE on solution for dynamic document •

Document Metadata – nearly complete:

Retrieve Documents – Purpose

The first step in the three-step process of retrieving data from another NHIE:

Subject Discovery Query for Documents

Retrieve Documents

Initiating Community

Document Consumer Retrieve Document Set [ITI-43] Initiating Gateway

Responding Community

Retrieve Documents – Purpose

•

Document Consumer

initiates a Retrieve Document Set transaction •

Initiating Gateway

processes Retrieve Document Set transaction and initiates Cross Gateway Retrieve ( Could be directed at multiple NHIEs) •

Responding Gateway

processes Cross Gateway Retrieve

Initiating Community

Document Consumer Retrieve Document Set [ITI-43] Initiating Gateway

Responding Community

Retrieve Documents – Approach Based on IHE’s XCA profile Retrieves patient relevant medical data held by another NHIE NHIEs will be identifiable by a globally unique id called the homeCommunityId

Retrieve Documents – Standards

IHE Cross Gateway Retrieve [ITI-39]

Cross Community Access (XCA) profile HITSP TP13

ebRIM OASIS/ebXML Registry Information Model v3.0

ebRS OASIS/ebXML Registry Services Specifications v3.0 SOAP 1.2. ( http://www.w3.org/TR/soap/ ) WSDL 1.1. ( http://www.w3.org/TR/wsdl ) MTOM SOAP Message Transmission Optimization Mechanism. ( http://www.w3.org/TR/soap12-mtom/ )

Retrieve Documents – Document Definition

A “document” refers to the form of clinical data as it is transferred between NHIEs, not as it is stored in an NHIE. Any NHIE may store clinical data in whatever format or repository it chooses, so long as the NHIE can respond to queries as described in the Query for Documents Interface, and respond to retrieve document requests as described in this interface. Specifically, a “document” transferred between NHIEs need not meet the criteria for persistence, stewardship, etc. as identified by the HL7 Structured Documents committee.

Retrieve Documents – Future

Expand to support asynchronous process: required on responding gateway, optional on initiating gateway

Audit Log Query

•

Purpose:

To provide the ability to exchange audit data associated with accessing health information •

Business need:

Allow consumers and privacy/security officers to determine who has had access to what records for what purpose for use and when they accessed the records •

Selected Standards:

IHE ATNA and Web Services •

Auditable data:

Audit Log Query – Future

No Changes Planned Until After September 30, 2009

Messaging

Craig Miller

Principles of NHIN Messaging Platform

• Provide a single common messaging platform for all NHIN messages – Web Services • Adopt a services-oriented architecture • Provide a flexible platform for innovation that can be extended as the network grows • Be neutral concerning networking topologies (peer-to-peer, hierarchical, hybrid models) 71 Copyright 2009. All Rights Reserved.

Scope of Messaging Subgroup

•

Message Transport

– – – – Enclosure Addressing Attachments Message Reliability •

Services Definition

– – Service Definition Language Policy Constraints •

Services Discovery

– NHIE Service Registry

Message Transport

Capability Message Enclosure Message Transport Message Addressing Specification

Simple Object Access Protocol (SOAP) Hypertext Transfer Protocol (HTTP) WS-Addressing

Message Attachments

Message Transmission Optimization Mechanism (MTOM)

Ver.

1.2

1.1

1.0

Notes

Upgraded from SOAP 1.1 in 2008

Reliable Messaging

WS-Reliable Messaging 1.2

Services Definition

Capability Services Definition Specification Ver.

Web Services Definition Language 1.1

Notes Policy Assertions

WS-Policy TBD Will provide capability for NHIEs to advertise specific policy constraints on invocation of services and specify which profiles they support New in 2009 74 Copyright 2009. All Rights Reserved.

Service Discovery: NHIE Service Registries

NHIEs require the ability to discovery the existence and capabilities of other NHIEs participating within the NHIN This is provided by NHIE service registries, which contain critical information about each NHIE needed to discover and connect to them

: – – – Name, location, contact information X.509 certificate public key – Network identifier (OID) Links to NHIE WSDL files Log in

Based on UDDI V3; XML-based, platform independent registry

NHIE Service Registry Infrastructure

• • • • Master Service Registry will be maintained by NHIN governance authority Slave nodes contain replicas of Master node content – Some maintained by NHIN governance authority, but any NHIE can elect to stand up their own slave node(s) Service Registry contains update notification capability – NHIEs can query the Registry once to obtain connection information for another NHIE and then cache the information locally to improve performance and minimize bandwidth bottlenecks

KEY

Replication Subscription Notification

Pull Model – Slave Nodes pull data from Master on scheduled basis

– Flush cache / re-query when notified of registry updates

NHIN UDDI Service Registry Slave Node #1

NHIN UDDI Service Registry Master Node

NHIN UDDI Service Registry Slave Node #2 NHIN UDDI Service Registry Slave Node #3 Push Model - Data change Notifications are sent out to all registered subscribers

Access to service registries requires valid NHIN x.509 digital CareSpark WestVA FED VA FED DoD NYCLIX HIXNY

…

Ensuring Interoperability

• NHIN utilizes a web services stack, but base specifications are sometimes ambiguous • We have elected to adopt Interoperability Profiles defined by the Web Services Interoperability Organization that further constrain service implementations to maximize interoperability • Currently adopted: – – Basic Profile 2.0

Security Profile 1.1

• Future adoption: – Reliable Secure Profile 1.0

Challenges and Next Steps

Ensuring all participants utilize a common version of the messaging platform Defining a vocabulary for policy assertions Deploying service registries into production

CONNECT Seminar Presentations are Available for Download Online at

http://www.connectopensource.org