Скачать презентацию Integrating the Healthcare Enterprise IHE Technical Committee Status Скачать презентацию Integrating the Healthcare Enterprise IHE Technical Committee Status

2b3f3d21f144e6e98759269fc9fff7bb.ppt

  • Количество слайдов: 24

Integrating the Healthcare Enterprise IHE Technical Committee Status IHE ITI Plan Committee - February Integrating the Healthcare Enterprise IHE Technical Committee Status IHE ITI Plan Committee - February 2004

IHE IT Infrastructure-2004 5 Integration Profiles Retrieve Information for Display Access a patient’s clinical IHE IT Infrastructure-2004 5 Integration Profiles Retrieve Information for Display Access a patient’s clinical information and documents in a format ready to be presented to the requesting user Patient Synchronized Applications Enterprise User Authentication Synchronize multiple applications on a desktop to the same patient Patient Identifier Cross-referencing for MPI Consistent Time Map patient identifiers across independent identification domains Coordinate time across networked systems Provide users a single name and centralized authentication process across all systems

IHE IT Infrastructure – Plan for 2004 -2005 • IT Infrastructure Development Plan: • IHE IT Infrastructure – Plan for 2004 -2005 • IT Infrastructure Development Plan: • • • IHE ITI Planning Committee decision: Issue Public Comment version: Public Comment Due: Issue Trial Implementation version: IHE Connectathon: HIMSS Demo: mid-February June 2004 July 2004 August 2004 January 2005 February 2005 • Profiles discussed this week are: • • Audit Trail and Node Authentication Personnel White Page Directory Patient Demographics Query EHR-Cross-Enterprise Clinical Document Sharing

IHE Authentication Audit Trail l Scope – Ensures that only permitted system/devices connect to IHE Authentication Audit Trail l Scope – Ensures that only permitted system/devices connect to network l l Authentication is node-to-node Note: User authentication covered by the EUA profile or local procedures. – Support for a central repository of audit information. Facilitates audit review and includes: l l l General security events such as logins, file access, and detection of unauthorized activity Healthcare privacy events such as access to patient data and applications. Imaging privacy/security events such as access to patient images.

IHE Authentication and Audit l Key technical properties – Node-to-node authentication uses X. 509 IHE Authentication and Audit l Key technical properties – Node-to-node authentication uses X. 509 certificates, but PKI is not specified by IHE yet. – Audit messages use a standardized XML format (IETF RFC Pending) – Transport for audit messages may use syslog or reliable syslog – Backwards compatibility with IHE Radiology (year 2002) is preserved.

Personnel White Pages Directory Scope Lab Reporting Healthcare Staff Info Electronic Medical Records Pharma Personnel White Pages Directory Scope Lab Reporting Healthcare Staff Info Electronic Medical Records Pharma White Pages Server Healthcare Staff Info Provide access to healthcare staff information to systems in a standard manner.

Personnel White Pages Directory Technical Properties l LDAP based directory location service l LDAP Personnel White Pages Directory Technical Properties l LDAP based directory location service l LDAP based requests of person info leveraging inet. Org. Person. l Specializes for Healthcare: Contact Info (Phone Numbers, email address, etc), and user interface friendly info (Salutation, First name, Last name, office building, user certificate list-no PKI). l Access certificate revocation list (no use rule defined).

Patient Demographics Query Abstract/Scope l Allow quick retrieval of common patient name, identifier, and Patient Demographics Query Abstract/Scope l Allow quick retrieval of common patient name, identifier, and location in a standard manner at the point of care. l Enable selection of correct patient when full identification data may not be available l Protect patient- and enterprise-sensitive clinical information

Patient Demographics Query Key Technical Properties l Employs HL 7 Conformance Based Queries – Patient Demographics Query Key Technical Properties l Employs HL 7 Conformance Based Queries – Defined in HL 7 Version 2. 5, Chapter 5 – Query by Parameter (QBP) with Segment Pattern Response (RSP) User enters identifiers for patients of interest l Server returns information in HL 7 V 2. 5 patient data segments. l

Introduction: EHR Cross-Enterprise Clinical Document Sharing First step towards the longitudinal dimension of the Introduction: EHR Cross-Enterprise Clinical Document Sharing First step towards the longitudinal dimension of the EHR: Focus: Clinical Information Exchange between EHRs in care settings to communicate with a distributed longitudinal EHR. Goal: Meet a broad range of EHR-LR (Longitudinal Record) needs with a distributed, cross-enterprise, document centric document content generic

Continuity of Care: Patient Longitudinal Record Nursing Homes Acute Care (Inpatient) Other Specialized Care Continuity of Care: Patient Longitudinal Record Nursing Homes Acute Care (Inpatient) Other Specialized Care (incl. Diagnostics Services) GPs and Clinics (Outpatient) Typically, a patient goes through a sequence of encounters in different Care Setting

EHR-LR Integration Profiles: Publishing & Accessing the EHR-LR Nursing Homes Acute Care (Inpatient) Other EHR-LR Integration Profiles: Publishing & Accessing the EHR-LR Nursing Homes Acute Care (Inpatient) Other Specialized Care or Diagnostics Services GPs and Clinics (Outpatient) The EHR-LR (Longitudinal Record) brings together patient encounter information managed by multiple care delivery systems

Two types of Integration : EHR-CR: Health Record as used during care delivery EHR-LR: Two types of Integration : EHR-CR: Health Record as used during care delivery EHR-LR: Health Record as used across-encounters EHR-LR Read Create Update EHR-CR Identification Selection of informations Decide to Assess demand For care Actions to order Define healthcare Objective Define an action plan End of Encounter Care Delivery Process EHR-Solution = EHR-LR (Longitudinal Record) + EHR-CR (Care Delivery Record)

Key Statements: EHR-LR Fundamentals • Brings together patient encounter information managed by all types Key Statements: EHR-LR Fundamentals • Brings together patient encounter information managed by all types of care delivery systems. • Cross-enterprise, possibly across large geographical regions, and may include many clinical domains. • Typically collected and retained over a large period of time, providing a deep historic record for the patient. • Supported by multiple repositories that contribute to the patient’s longitudinal healthcare record. • Encounter data will very likely include some clinical documents, state and workflow information that will not be stored in the EHR-LR.

Key Statements: What is in the EHR-LR? • The EHR-LR data is made of Key Statements: What is in the EHR-LR? • The EHR-LR data is made of discrete, persistent, clinical documents accessed by an unique identifier. • It may also contain other dynamic objects which are not being addressed by IHE at this time. • Metadata will be provided with each document by the EHR-CR and will be stored in the EHR-LR. • EHR-LR data formats will follow relevant clinical domain standards defined by field experts. EHR-CR is responsible for converting its internal data formats to the standard EHR-LR documents. • EHR-LR documents will kept in the EHR-CR or pushed to a separate EHR-LR repository.

Key Statements: IHE EHR Profiles Constraints • Although the EHR-LR data domains are primarily Key Statements: IHE EHR Profiles Constraints • Although the EHR-LR data domains are primarily clinical, other information and services are needed to provide a complete view of the patient longitudinal record. These include patient demographics, access security, consent policies and others – some have already been addressed by IHE integration profiles. • The EHR-LR and EHR-CR repositories may be using different Patient Identification numbers. The longitudinal view is made possible by using standard cross-patient identification services (IHE PIX Integration Profile). • The way data is stored and managed internally by the EHR-CR is out of scope for the EHR-LR IHE Integration Profiles.

Key Statements: Accessing the EHR-LR • EHR-LR shall make available a list of all Key Statements: Accessing the EHR-LR • EHR-LR shall make available a list of all published documents for a given patient/selection parameters. • The selection of documents is the responsibility of the EHRLR and not of the consumer applications. This is possible because of the document metadata kept in the EHR-LR. • The EHR-LR must ensure full content fidelity for all clinical documents that have been published. • The actual location of any particular document shall be transparent to the consumer application. • EHR-CR may provide clinical data by processing, extracting, or combining multiple documents.

Key Statements: Deploying IHE EHR-LR Profiles • The deployment of EHR-LR integration profiles will Key Statements: Deploying IHE EHR-LR Profiles • The deployment of EHR-LR integration profiles will initially be focused on a small number of specialties (cardiology, oncology, etc), disease, and/or on key information for continuity of care (e. g. CCR summaries). • The scope of the EHR-LR profiles will expand progressively as other specialties are included in the use cases.

EHR-LR Integration Profile: Key Actors (Application Roles) l EHR-CR Source – Healthcare point of EHR-LR Integration Profile: Key Actors (Application Roles) l EHR-CR Source – Healthcare point of service system where clinical information is first collected l EHR-LR Directory – Index and metadatabase for all published clinical documents l EHR-LR Documents Repository – Maintains and stores published EHR-LR documents l EHR-CR Consumer – Application system that needs access to EHR-LR documents and information

Integration Model 1: EHR-LR with Source Repository 1. An EHR-CR completes a phase of Integration Model 1: EHR-LR with Source Repository 1. An EHR-CR completes a phase of care for a patient where it: 1. Registers documents with an EHR-LR Directory actor. 2. Keeps these documents in an EHR-LR Repository actor. 2. Any other EHR-CR may query an EHR-LR Directory actor, find out about documents related to all phases of care for the patient and chose to retrieve some of these documents from any EHRLR Repository Actor (Used in use Case 1 & 2). Register EHR-CR Source EHR-LR Repository EHR-LR Directory Retrieve Query EHR-LR Consumer

Integration Model 2: EHR-LR with Third Party Repository 1. An EHR-CR completes a phase Integration Model 2: EHR-LR with Third Party Repository 1. An EHR-CR completes a phase of care for a patient where it: 1. Registers documents with an EHR-LR Directory Actor. 2. Provides these documents to an EHR-LR Repository Actor. 2. Any other EHR-CR may query an EHR-LR Directory Actor, find out about documents related to all phases of care for the patient and chose to retrieve some of these documents from any EHRLR Repository Actor (Used in use Case 1 & 2). Register EHR-CR Source Provide-Transfer EHR-LR Directory EHR-LR Repository Query EHR-LR Consumer Retrieve

Integration Model 3: Direct Patient Transfer-Referral 1. An EHR-CR completes a phase of care Integration Model 3: Direct Patient Transfer-Referral 1. An EHR-CR completes a phase of care for a patient where it: • Registers and Provides an EHR-CR Recipient Actor that a specific set of documents (newly created and priors of interest documents) are available from an EHR-LR Repository 2. The EHR-CR Recipient Actor receive both the registration and the documents. EHR-CR Source Register Provide-Transfer EHR-CR Consumer EHR-LR Directory EHR-LR Repository

Conclusion: EHR Cross-Enterprise Document Sharing • Leverages HL 7 CDA (Clinical Document Architecture) and Conclusion: EHR Cross-Enterprise Document Sharing • Leverages HL 7 CDA (Clinical Document Architecture) and ASTM CCR (Continuity of Care Record). • The proposed strategy addresses one of the key integration problems in the realization of the EHR vision. IHE does not claim to master and address the definition and all aspects of a complete and interoperable EHR System. • In collaboration with well established standards bodies and other EHR related initiatives world-wide (EHRCOM, CCR, HL 7, etc. ), IHE expects to contribute at a more cost-effective and rapid deployment.

IHE IT Infrastructure • To join IT Infrastructure planning or technical committee: • Contact IHE IT Infrastructure • To join IT Infrastructure planning or technical committee: • Contact Joyce Sensmeier, HIMSS. [email protected] org • Suggest new profiles to IHE IT Infrastructure Planning • Produce new profiles in IHE IT Infrastructure Technical Committee