IT Infrastructure for the Enteprise Mike Henderson Principal Consultant, Eastern Informatics Past...

IT Infrastructure for the Enteprise

IT Infrastructure for the Enteprise

Mike HendersonPrincipal Consultant, Eastern Informatics

Past co-Chair, IT Infrastructure Technical Committee

Charles ParisotGE Healthcare

Co-Chair, IT Infrastructure Technical Committee

June 28-29, 2005 Interoperability Strategy Workshop2

W W W . I H E . N E TW W W . I H E . N E T

Providers and VendorsWorking Together to Deliver

Interoperable Health Information SystemsIn the Enterprise

and Across Care Settings


Integration ProfilesIntegration Profiles

• PDQ• PIX• PAM• EUA• PWP• PSA• RID • CT + ATNA (Already Addressed)


IT Infrastructure ProfilesIT Infrastructure Profiles

2004 Patient Identifier Cross-referencing for MPI (PIX) Retrieve Information for Display (RID) Consistent Time (CT) Patient Synchronized Applications (PSA) Enterprise User Authentication (EUA)

2005Patient Demographic Query (PDQ) Cross Enterprise Document Sharing (XDS)Audit Trail and Note Authentication (ATNA)Personnel White Pages (PWP)

2006Cross-Enterprise User Authentication (XUA)Document Digital Signature (DSG) – Notification of Document Availability (NAV)Patient Administration/Management (PAM)

Patient Demographic Query (PDQ)

Patient name, Patient ID


Patient Demographics QueryPatient Demographics QueryAbstract / ScopeAbstract / Scope

• Allow quick retrieval of a patient list including common patient names, identifiers, contacts, and visit information

• Enable selection of correct patient when full identification data may not be available

• Limits access to only a subset of demographic and visit information


Patient Demographics QueryPatient Demographics QueryValue PropositionValue Proposition

• Enables access on demand to diverse systems and devices

– Participants that do not need continual synchronization of patient registration information

– Devices that cannot participate in monitoring of ADT feeds, e.g.:

• Small-footprint devices

• Low-memory devices

• Allow search on full or partial data


Patient Demographics QueryPatient Demographics QueryTransaction DiagramTransaction Diagram

A departmental system that is A departmental system that is connected on demand to the connected on demand to the registration system.registration system.

Diverse systems including Diverse systems including bedside monitors, physician bedside monitors, physician office systems, lab applications, office systems, lab applications, mobile blood bank registries; mobile blood bank registries; might be any system at the point might be any system at the point of contact.of contact.

HL7 Version 2.5, Chapter 5






Patient Identifier Cross-referencing for MPI (PIX)

(Map patient identifiers across independent identification domains)


Patient Identifier Cross-referencing for MPIPatient Identifier Cross-referencing for MPIAbstract / ScopeAbstract / Scope

• Allow all enterprise participants to register the identifiers they use for patients in their domain

• Participants retain control over their own domain’s patient index(es)

• Support domain systems’ queries for other systems’ identifiers for their patients

• Optionally, notify domain systems when other systems update identifiers for their patients


Patient Identifier Cross-referencing for MPIPatient Identifier Cross-referencing for MPIValue PropositionValue Proposition

• Maintain all systems’ identifiers for a patient in a single location

• Use any algorithms (encapsulated) to find matching patients across disparate identifier domains

• Lower cost for synchronizing data across systems– No need to force identifier and format changes onto existing

systems• Leverages standards and transactions already used

within IHE


Patient Identifier Cross-referencing for MPIPatient Identifier Cross-referencing for MPI

Patient Identification Domain A

Patient Identification Domain C

Id=X456 Id=Y921 Id=D456 Id=DF45

Patient Identification

Cross -reference Domain

Patient Identification Domain B

Id=123 Id=235

Id=3TY Id=2RT

Patient Identity Cross - reference Manager

B: X456 = C: 2RT A: 123 = B: Y 921 = C: 3TY B :D456

A :235 = B: DF45 A:678

Patient Identity Consumer

B:X456C: 2RT

IdentityPatientCross References

B:X456C: ?


PIX Integration Profile & MPIPIX Integration Profile & MPIThe typical viewThe typical view

Patient Identification Domain C

Patient Identity Cross-reference Manager

Patient Identification Domain A(Master Domain)

Patient Identification Domain B

Master (A) PatientIdentity Source

Master PatientIndex






Patient Administration & Management (PAM)

Patient Identification, Admission, Movements &

Encounters


Patient Administration ManagementPatient Administration ManagementAbstract / ScopeAbstract / Scope

• Coordinates exchange of patient registrations, updates, and movements for all clinical areas

• Information may be received and processed by consumer applications in any clinical domain

• Optionally allows unambiguous updating of historic patient movement events

• Demographic and encounter tracking works in both inpatient and ambulatory care settings


Patient Administration Management Patient Administration Management Value PropositionValue Proposition

• Optional support levels allow products to offer “light” or “rich” functionality

• Aligns legacy IHE Radiology and IT Infrastructure transactions with the latest HL7 standard– Permits robust error reporting and automated

exception processing• Standardizes on HL7 conformance structures

– Reduces variance among vendor and implementor specification formats


Patient Administration Management Patient Administration Management Transaction DiagramTransaction Diagram

Patient Demographics

SourcePatient Demographics

Consumer

Patient Encounter Source

Patient Encounter Consumer

Patient Identity Feed

Patient Encounter Management


Patient Administration Management Patient Administration Management Actor Grouping RequirementsActor Grouping Requirements

OR

Patient Demographics Source

Patient Demographics Consumer



← Patient Identity Feed [ITI-030]

→ Patient Encounter Management [ITI-031]

Patient Demographics Consumer



Patient Demographics Source

→ Patient Identity Feed [ITI-030]

→ Patient Encounter Management [ITI-031]


Patient Administration Management Patient Administration Management Standards UsedStandards Used

HL7 Version 2.5– ADT Registration, Update, and Patient Movement

Trigger Events• Admission/registration• Merge, update, link/unlink• Movement management


Patient Administration Management Patient Administration Management ActorsActors

Patient Demographics Source– Definition

• Responsible for maintaining demographics (name, address, etc.) about patient and related persons

• Supplies new and updated information to Patient Demographics Consumer

– Transaction Supported - Required• Patient Identity Feed [ITI-30] (as sender)



Patient Demographics Consumer– Definition

• Uses demographic information provided by the Patient Demographics Source about a patient

– Transaction Supported – Required• Patient Identity Feed [ITI-30] (as receiver)



Patient Encounter Source– Definition

• Responsible for maintaining encounter information about a patient

• Supplies new and updated information to the Patient Encounter Consumer

• Must be grouped with either Patient Demographics Source or Patient Demographics Consumer

– Transaction Supported - Required• Patient Encounter Management [ITI-31] (as sender)



Patient Encounter Consumer– Definition

• Uses patient encounter information provided by Patient Encounter Source

– Transaction Supported - Required• Patient Encounter Management [ITI-31] (as receiver)


Patient Administration Management Patient Administration Management Patient Id Mgt TransactionsPatient Id Mgt Transactions

Patient Identity Feed [ITI-30]– Definition

• Patient Demographics Source registers or updates patient• Forwards ID, address, NOK, guarantor, etc., to other systems

implementing Patient Demographics Consumer

– Options• Merge• Link/Unlink


Patient Administration Management Patient Administration Management Patient Encounter Mgt TransactionsPatient Encounter Mgt Transactions

Patient Encounter Management [ITI-31]– Definition

• Patient Encounter Source registers or updates an encounter• Forwards encounter information to other systems implementing Patient

Encounter Consumer– Location– Providers– Dates, times, etc.

– Options• Inpatient/Outpatient Encounter Management• Pending Event Management• Advanced Encounter Management• Temporary Patient Transfer Tracking• Historic Movement Management


Patient Administration Management Patient Administration Management Encounter Management OptionsEncounter Management Options

Inpatient/Outpatient Encounter Management– HL7 Trigger Events

• Admit inpatient (A01/A11)• Register outpatient (A04/A11)• Discharge patient (A03/A13)• Update patient information (A08)• Pre-admit patient (A05/A38)• Change outpatient to inpatient (A06)• Change inpatient to outpatient (A07)• Transfer patient (A02/A12)



Pending Event Management– Additional HL7 Trigger Events

• Pending admit (A14/A27)• Pending transfer (A15/A26)• Pending discharge (A16/A25)



Advanced Encounter Management– Additional HL7 Trigger Events

• Change attending doctor (A54/A55)• Leave of absence (A21/A52)• Return from leave of absence (A22/A53)• Move account information (A44)• Merge patient ID list (A40)



Temporary Patient Transfers Tracking– Additional HL7 Trigger Events

• Patient departing – tracking (A09/A33)• Patient arriving – tracking (A10/A32)



Historic Movement Management– Uses trigger events of any of the above options that

have been adopted– Adds ZBE segment to contain a unique identifier for

the movement• Standard segment pending adoption by HL7

– Adds Z99 trigger event to allow update of any movement information, based on unique ID in ZBE segment

• Standard trigger event pending adoption by HL7






Enterprise User Authentication (EUA)

Single user name & centralized authentication


Enterprise User AuthenticationEnterprise User AuthenticationScopeScope

• Support a single enterprise governed by a single set of security policies and having a common network domain.

• Establish one name per user to be used for all IT applications and devices.

• Facilitate centralized user authentication management.

• Provide users with single sign-on.


Enterprise User AuthenticationEnterprise User AuthenticationValue PropositionValue Proposition

• Meet a basic security requirement– User authentication is necessary for most applications and

data access operations.• Achieve cost savings/containment

– Centralize user authentication management– Simplify multi-vendor implementations

• Provide workflow improvement for users– Increase user acceptance through simplicity– Decrease user task-switching time.

• More effective security protection– Consistency and simplicity yields greater assurance.


Enterprise User Authentication Enterprise User Authentication Use Case: Single Sign OnUse Case: Single Sign On

• Motivation– Users need to frequently communicate with many non-

integrated IT application services.– Managing multiple user identities and passwords is

costly to users and system administration. • Solution

– EUA supports a single common user identity for browser-based applications.

– EUA allows multiple user authentication technologies.

– EUA uses well-trusted standardized user identity mechanisms: Kerberos and CCOW user context.


Enterprise User AuthenticationEnterprise User AuthenticationTransaction DiagramTransaction Diagram


Enterprise User AuthenticationEnterprise User AuthenticationTransaction Diagram: CCOW OptionTransaction Diagram: CCOW Option






Personnel White Pages (PWP)

Access to workforce contact information


Personnel White Pages (PWP) – Personnel White Pages (PWP) – Abstract/ScopeAbstract/Scope

• Provide access to basic information about the human workforce members– Does not include Patients

• Defines method for finding the PWP

• Defines query/access method

• Defines attributes of interest


Personnel White Pages (PWP) – Personnel White Pages (PWP) – Value PropositionValue Proposition

• Single Authoritative Knowledge Base – Reduce duplicate and unconnected user info database– Single place to update

• Name Changes• New Phone Number• Additional Addresses

• Enhance Workflow and Communications– Providing information necessary to make connections

• Phone Number• Email Address• Postal Address


Personnel White Pages (PWP) – Personnel White Pages (PWP) – Value Proposition Value Proposition

• Enhance User Interactions– Provide user friendly identities and lists

• List of members• Displayable name of a user• Initials query

• Contributes to Identity Management– Additional methods of identity cross verification

• Name, address, phone number, email• Cross reference with Enterprise User Authentication identity

– Future expansion likely will contain certificates


PWP - TransactionsPWP - Transactions

PersonnelWhitePages

ConsumerQuery for Healthcare Workforce Member Info

Provide access to healthcare staff informationProvide access to healthcare staff information to systems in a standard manner. to systems in a standard manner.

PersonnelWhite Pages

Directory

DNS Server

Find PersonnelWhite Pages






Patient Synchronized Applications (PSA)

Tune multiple applications to same patient


Abstract / Scope

• Patient Synchronization of Multiple Disparate Applications

• Single Patient Selection

• When combined with PIX Profile, allows patient synchronization across patient identifier domains

• When combined with EUA Profile, provides user Single Sign-on (SSO)

Patient Synchronized ApplicationsPatient Synchronized Applications


Value Proposition• User Convenience:

– Eliminates the repetitive task of selecting the patient in each application– Permits the user to select the patient in the application for which they are

most familiar and / or appropriate to the clinical workflow

• Patient Safety:– Ensures all data being viewed across applications is for the same patient

• Leverage Single Development Effort:– Allows vendors to leverage single CCOW enablement effort to support

multiple actors:• Patient Context Participant (PSA)• User Context Participant (EUA)



Patient Synchronized ApplicationsPatient Synchronized ApplicationsActorsActors

Context Manager Actor• The IHE Context Manager Actor may encompass

more than a CCOW context manager function. It may include a number of other components such as the context management registry and patient mapping agent.

Patient Context Participant Actor• The Patient Context Participant Actor shall

respond to all patient context changes. This actor shall set the patient context provided the application has patient selection capability.


Transactions Diagram


These transactions are required by both Actors to claim compliance


Simple Patient Switching ProcessSimple Patient Switching Process

Change Context [6]

Follow Context [13]

Patient Context Participant 1 (clinical data repository)

Context Manager

User closes application

Join Context [5]

Patient Context Participant 2 (cardiology)

Join Context [5]

Change Context [6]

Follow Context [13]

Leave Context [7]

Leave Context [7]

User closes application

User selects patient A

User selects patient B

Application tunes to patient A






Retrieve Information for Display (RID)

Access patient clinical summaries in presentation

format


• Simple and rapid access to patient information

• Access to existing persistent documents in well-known presentation formats: CDA, PDF, JPEG.

• Access to specific key patient-centric information for presentation to a clinician : allergies, current medications, summary of reports, etc..

• Links with other IHE profiles - Enterprise User Authentication, Patient Identifier Cross-referencing and Cross Enterprise Document Sharing

Retrieve Information for DisplayRetrieve Information for DisplayAbstract / ScopeAbstract / Scope


• User Convenience:– Healthcare providers can "see" the information. A significant

integration step.

– Workflows from within the users’ on-screen workspace or application.

– Complements multiple simultaneous apps workflow of Patient Synchronized Apps

• Broad Enterprise-Wide access to information:– Web technology for simple clients– Clinical data handling fully assumed by the information source

that holds clinical data.

Retrieve Information for DisplayRetrieve Information for DisplayValue PropositionValue Proposition


• Standards Used:– Web Services (WSDL for HTTP Get).– General purpose IT Presentation Formats: XHTML, PDF, JPEG, CDA L1

(HL7)

– Client may be off-the-shelf browser or display application.

• Two services :– Retrieve of Specific Information:

• Patient centric: patient ID• Type of Request (see next slide)• Date, Time, nMostRecent

– Retrieve a Document• Object Unique Instance Identifier (OID)• Type of Request• Content Type Expected

Retrieve Information for DisplayRetrieve Information for DisplayKey Technical PropertiesKey Technical Properties


Transaction Diagram

Retrieve Information for DisplayRetrieve Information for Display

Display InformationSource

Retrieve Specific Info for Display [11]

Summary of Laboratory Reports

Summary of Radiology ReportsSummary of Cardiology ReportsSummary of Surgery ReportsSummary of Intensive Care ReportsSummary of Emergency ReportsSummary of Discharge ReportsList of AllergiesList of Medications

Retrieve Document for Display [12]

Persistent Document

Types ofRequests

Summary of All Reports

Summary of Prescriptions


Retrieve Information for DisplayRetrieve Information for Display

• Retrieved Data Presentation and Format

- Non Persistent Data Content and Presentation is left to the Information Source Actor.

- Persistent Data Documents are provided by the Information Source Actor in one of the Display Actor proposed formats: JPEG, PDF, CDA L1






Audit Trail and Node Authentication (ATNA) –

Centralized privacy audit trail and node to node authentication to

create a secured domainConsistent Time (CT) – Coordinate

time across network systems


ATNAATNAValue PropositionValue Proposition

• Protect Patient Privacy and System Security:– Meet ethical and regulatory requirements

• Enterprise Administrative Convenience:– Unified and uniform auditing system– Common approach from multiple vendors simplifies definition

of enterprise policies and protocols.– Common approach simplifies administration

• Development and support cost reduction through Code Re-use:– Allows vendors to leverage single development effort to

support multiple actors– Allows a single development effort to support the needs of

different security policies and regulatory environments.


ATNAATNASecurity RequirementsSecurity Requirements

• Reasons: Clinical Use and Privacy– authorized persons must have access to medical data of

patients, and the information must not be disclosed otherwise.– Unauthorized persons should not be able to interfere with

operations or modify data

• By means of procedures and security mechanisms, guarantee:– Confidentiality– Integrity– Availability– Authenticity


ATNAATNASecurity MeasuresSecurity Measures

• Authentication:Authentication: Establish the user and/or system identity, answers question: “Who are you?”

• ATNA defines: How to authenticate network connections.• ATNA Supports: Authentication mechanisms, e.g. Enterprise User

Authentication (EUA) or Cross Enterprise User Authentication (XUA)..

• Authorization and Access control:Authorization and Access control:Establish user’s ability to perform an action, e.g. access to data, answers question: “Now that I know who you are, what can you do?”

• ATNA defines: How to authorize network connections.• ATNA requires: System internal mechanisms for both local and

network access.


ATNAATNASecurity MeasuresSecurity Measures

• Accountability and Audit trail:Accountability and Audit trail:Establish historical record of user’s or system actions over period of time, answers question: “What have you done?”

• ATNA Defines: Audit message format and transport protocol


ATNAATNAIHE GoalIHE Goal

• IHE makes cross-node security management easy:– Only a simple manual certificate installation is needed,

although more sophisticated systems can be used

– Separate the authentication, authorization, and accountability functions to accommodate the needs of different approaches.

– Enforcement driven by ‘a posteriori audits’ and real-time visibility.


ATNAATNAIntegrating Trusted NodesIntegrating Trusted Nodes

System A System B

Secured SystemSecure network

• Strong authentication of remote node (digital certificates)• network traffic encryption is not required, it is optional

Secured System

• Local access control (authentication of user)

• Audit trail with:• Real-time access • Time synchronization

Central Audit TrailRepository


ATNAATNANode AuthenticationNode Authentication

• X.509 certificates for node identity and keys• TCP/IP Transport Layer Security Protocol (TLS) for

node authentication, and optional encryption• Secure handshake protocol of both parties during

Association establishment:– Identify encryption protocol– Exchange session keys

• Actor must be able to configure certificate list of authorized nodes.

• ATNA presently specifies mechanisms for HTTP, DICOM, and HL7


ATNAATNAAuditing SystemAuditing System

• Designed for surveillance rather than forensic use.• Two audit message formats

– IHE Radiology interim format, for backward compatibility with radiology

– IETF/DICOM/HL7/ASTM format, for future growth• DICOM Supplement 95• IETF Draft for Common Audit Message• ASTM E.214• HL7 Audit Informative documents

• Both formats are XML encoded messages, permitting extensions using XML standard extension mechanisms.


What it takes to be a secure nodeWhat it takes to be a secure node

• The entire host must be secured, not just individual actors.

• The entire host must have appropriate user access controls for identification, authentication, and authorization.

• All communications that convey protected information must be authenticated and protected from interception. This means every protocol, not just the IHE transactions.

• All health information activities should generate audit trails, not just the IHE actors.


IHE and PHI ProtectionIHE and PHI Protection

• User Identity → PWP, EUA• User Authentication → EUA, XUA• Node Authentication → ATNA• Security Audit Trails → ATNA• Data Integrity Controls → CT, ATNA TLS option• Data Confidentiality → ATNA TLS option• Access Controls → Future item in IHE roadmap


More information….More information….

• IHE Web sites: www.ihe.net• Technical Frameworks, Supplements

• ITI V1.0, RAD V5.5, LAB V1.0

• Non-Technical Brochures :• Calls for Participation

• IHE Fact Sheet and FAQ

• IHE Integration Profiles: Guidelines for Buyers

• IHE Connect-a-thon Results

• Vendor Products Integration Statements

http://www.ihe.net/

Date post:	05-Jan-2016
Category:	Documents
Upload:	ethelbert-welch
View:	212 times
Download:	0 times