Presentation is loading. Please wait.

Presentation is loading. Please wait.

October 2010IHE Orientation-Cyprus 1 INTEGRATING THE HEALTHCARE ENTERPISE (IHE) Orientation Workshop TurkMIA Conference-10 Charles Parisot, IHE-Europe.

Similar presentations


Presentation on theme: "October 2010IHE Orientation-Cyprus 1 INTEGRATING THE HEALTHCARE ENTERPISE (IHE) Orientation Workshop TurkMIA Conference-10 Charles Parisot, IHE-Europe."— Presentation transcript:

1 October 2010IHE Orientation-Cyprus 1 INTEGRATING THE HEALTHCARE ENTERPISE (IHE) Orientation Workshop TurkMIA Conference-10 Charles Parisot, IHE-Europe Steering Committee & International Board member, GE healthcare

2 2 Agenda This Morning: Part 1: THE IHE STANDARDS ADOPTION PROCESS: achieving practical interoperability This Afternoon: Part 2: USERS AND VENDORS WORKING TOGETHER: how can I contribute & benefit from IHE HOW TO USE IHE RESOURCES: hands on experience

3 3 Agenda Part 1: THE IHE STANDARDS ADOPTION PROCESS: achieving practical interoperability

4 4 IHE: A Framework for Interoperability A common framework for harmonizing and implementing multiple standards Application-to-application Application-to-application System-to-system System-to-system Setting-to-setting Setting-to-setting Enables seamless health information movement within and between enterprises, regions, nations Promotes unbiased selection and coordinated use of established healthcare and IT standards to address specific clinical needs

5 5 Standards: Necessary…Not Sufficient Standards are Foundational - to interoperability and communications Foundational - to interoperability and communications Broad - varying interpretations and implementations Broad - varying interpretations and implementations Narrow - may not consider relationships between standards domains Narrow - may not consider relationships between standards domains Plentiful - often redundant or disjointed Plentiful - often redundant or disjointed Focused - standards implementation guides focus only on a single standard Focused - standards implementation guides focus only on a single standard IHE provides a standard process for implementing multiple standards

6 6 IHE: Connecting Standards to Care Healthcare professionals work with industry Coordinate implementation of standards to meet clinical and administrative needs Clinicians and HIT professionals identify the key interoperability problems they face Clinicians and HIT professionals identify the key interoperability problems they face Providers and industry work together to develop and make available standards-based solutions Providers and industry work together to develop and make available standards-based solutions Implementers follow common guidelines in purchasing and integrating effective systems Implementers follow common guidelines in purchasing and integrating effective systems IHE: A forum for agreeing on how to implement standards and processes for making it happen

7 7 Standards Adoption Process Document Use Case Requirements Identify available standards ( e.g. HL7, DICOM, IETF, OASIS) Develop technical specifications Testing at Connectathons IHE Demonstrations Products with IHE Timely access to information Easy to integrate products

8 8 Stakeholder Benefits Healthcare providers and support staff Improved workflows Improved workflows Information whenever and wherever needed Information whenever and wherever needed Fewer opportunities for errors Fewer opportunities for errors Fewer tedious tasks/repeated work Fewer tedious tasks/repeated work Improved report turnaround time Improved report turnaround timeVendors Align product interoperability with industry consensus Align product interoperability with industry consensus Decreased cost and complexity of interface installation and management Decreased cost and complexity of interface installation and management Focus competition on functionality/service space not information transport space Focus competition on functionality/service space not information transport spaceSDOs Rapid feedback to adjust standards to real-world Rapid feedback to adjust standards to real-world Establishment of critical mass and widespread adoption Establishment of critical mass and widespread adoption

9 9 IHE Implementation Strategy Leverage established standards to allow rapid deployment and plan for future Pragmatic, Ease of Evolution Enable architectural freedom (patient vs. provider centric, centralized vs. decentralized, scalable (from office to enterprise to IDN to Regional and National Networks) Configuration flexibility Support breakthrough use cases: variety of care settings, care coordination, public health, PHR, EHR Interoperability for broad constituencies IHE: Offers consistent, standards-based record sharing for EHRs and other information systems

10 10 12 Years of Steady Growth 1998 – 2010 The IHE Development Domains Pharmacy NEW 2009 Pathology since 2006 Radiation Oncology since 2004 Radiology since 1998 Cardiology since 2004 Patient Care Devices since 2005 Patient Care Coordination since 2004 Eye Care since 2006 Quality Research & Public Health since 2006 Laboratory since 2004 (Healthcare) IT Infrastructure since 2003

11 11 International Growth of IHE France Local Deployment, National Extensions Promotional & Live Demonstration Events Over 300 Organizational Members (all stakeholders) USA Germany Italy Japan UK Canada Taiwan Netherlands Spain Austria 199920002001200220032004 2005200620072009 Pragmatic global standards harmonization + best practices sharing 2008 Australia 2010 China Turkey Malaysia Switzerland

12 12 IHE Integration Profiles - Model Actors in precisely defined roles Abstracts a specific function of information system Abstracts a specific function of information system …Executing precisely defined transactions Using existing standards Using existing standards ……To solve real world interoperability problems Specifying Integration Profiles Specifying Integration Profiles

13 13 Key IHE Concepts Generalized Systems -> ActorsGeneralized Systems -> Actors Interactions between Actors -> TransactionsInteractions between Actors -> Transactions Problem/Solution Scenarios-> Integration ProfilesProblem/Solution Scenarios-> Integration Profiles For each Integration Profile:For each Integration Profile: the context is described (which real-world problem)the context is described (which real-world problem) the actors are defined (what systems are involved)the actors are defined (what systems are involved) the transactions are defined (what must they do)the transactions are defined (what must they do)

14 14 The Product World….. Product XYZ from Vendor T

15 15 The IHE World…. IHE Actor Actor Actor Actor IHE Transaction IHE Actor

16 16 Mapping IHE to Products Product XYZ from Vendor T IHE Actor Actor Actor Actor IHE Transaction IHE Actor

17 17 Organization of Technical Frameworks Volume 1: Integration and content Profiles Describes clinical need and use cases Describes clinical need and use cases Identifies : Identifies : the actors and transactions or, the actors and transactions or, content modules content modules Volume 2+ of Technical Framework Provides implementation specification for transactions or content modules Provides implementation specification for transactions or content modules

18 18 IHE and Service Oriented Architectures SOA is a powerful business driven design methodology SOA wraps interoperability in services, but does not solve interoperability: E.g. Web Services may or may not be used in SOA. IHE Profiles are largely (not always) based on Web Services. E.g. Web Services may or may not be used in SOA. IHE Profiles are largely (not always) based on Web Services. Standardizing Services offered along with the protocols is 20 years old (Open System Interconnect). Good, but a Service definition does not result in compatibility on the wire. Standardizing Services offered along with the protocols is 20 years old (Open System Interconnect). Good, but a Service definition does not result in compatibility on the wire. IHE Integration profiles are supportive of Service Oriented Architecture, but do not require use of SOA. IHE is Service Aware ! Bits have to be compatible on the wire: No way to avoid specifying transaction & content Bits have to be compatible on the wire: No way to avoid specifying transaction & content

19 19 Standards Adoption Process Document Use Case Requirements Identify available standards ( e.g. HL7, DICOM, IETF, OASIS) Develop technical specifications Testing at Connectathons IHE Demonstrations Products with IHE Timely access to information Easy to integrate products

20 20 IHE Connectathon Open invitation to vendor and other implementors community Advanced testing tools (GAZELLE) Testing organized and supervised by project management team Thousands of cross-vendor tests performed Results recorded and published

21 21 Massive yearly events : 70-80 vendors 250-300 engineers 100-120 systems ….integrated in 5 days IHE Connectathons Vendors do not pass… until an IHE Project Manager attest it ! Last Connectathon: Chicago, USA, January 11-15, 2010 Bordeaux, France, April 12-16, 2010

22 22 http://www.ihe.net/Connectathon/index.cfm

23 23 Leveraging IHE Integration Statements Vendors Claim IHE Compliance in an explicit way Claim IHE Compliance in an explicit way Can rely on an objective and thorough specification (IHE Technical Framework) Can rely on an objective and thorough specification (IHE Technical Framework) Willing to accept contractual commitments Willing to accept contractual commitments Willing to correct implementation errors Willing to correct implementation errorsBuyers Can compare product integration capabilities Can compare product integration capabilities Simplify and strengthen their RFPs Simplify and strengthen their RFPs Can leverage a public and objective commitment Can leverage a public and objective commitment Decreased cost and complexity of interface deployment and management Decreased cost and complexity of interface deployment and management

24 24 IHE Demonstrations: NOT an IHE Connectathon IHE Connectathon is about qualifying real-world implementations. Strict process and controlled technical testing activity. It is the stick ! It is the stick ! IHE demonstration is about education and promotion about what some connectathon tested implementations can achieve. It is the carrot ! It is the carrot ! Implementations participating to an IHE Demonstration are required to have passed an IHE Connectahon. Not all vendors and products are demonstrated.

25 25 HIMSS Interoperability Showcase

26 26 Example: 2010 HIMSS Interoperability Showcase

27 Implementation Tools (1) Open source implementations are available for XDS, XCA, XCPD, PIX, PDQ, ATNA, CT, and more: Microsoft under codeplex http://ihe.codeplex.com/ http://ihe.codeplex.com/ NIST under Source Forge http://sourceforge.net/projects/iheos/ http://sourceforge.net/projects/iheos/ HIE-OS under Source Forge http://sourceforge.net/projects/hieos/ http://sourceforge.net/projects/hieos/ FHA CONNECT http://www.connectopensource.org http://www.connectopensource.org More on the next page….. 27

28 September, 2005 28 Open source implementations are available for XDS, XCA, XCPD, PIX, PDQ, ATNA, CT, and more, from Open Health Tools: http://www.projects.openhealthtools.org http://www.projects.openhealthtools.org OHT – IHE Profiles (Charter) https://iheprofiles.projects.openhealthtools.org https://iheprofiles.projects.openhealthtools.org OHT – Open Exchange (Forge) https://openexchange.projects.openhealthtools.org OHT – Model Driven Health Tools (Charter) https://mdht.projects.openhealthtools.org https://mdht.projects.openhealthtools.org Implementation Tools (2)

29 29 Providers and Vendors Working Together to Deliver Interoperable Health Information Systems in the Enterprise and http://www.ihe.net Across Care Settings

30 30 Requirements for an open HIE/EHR Bring trust and ease of use for healthcare professionals: Care delivery organizations choose information to share: Care delivery organizations choose information to share: Based on patient health status Based on patient health status When they see fit (discharge, end of encounter, etc.) When they see fit (discharge, end of encounter, etc.) What information to share (pick relevant documents, and content elements). What information to share (pick relevant documents, and content elements). Care delivery organizations access patient info through: Care delivery organizations access patient info through: Their own local EMR (if they have one) Their own local EMR (if they have one) Through a shared portal/service otherwise. Through a shared portal/service otherwise. When accessing patient info: When accessing patient info: Find quickly if relevant information is available or not (single query) Find quickly if relevant information is available or not (single query) May select among relevant records (may be done in background) May select among relevant records (may be done in background) Among them chose to import whole or part in local patient record Among them chose to import whole or part in local patient record

31 31 Requirements for an open HIE/EHR(2) Bring trust and privacy to patients: Only authorized organizations and authenticated healthcare providers may transact in the HIE: Only authorized organizations and authenticated healthcare providers may transact in the HIE: Each node or IT system interfaced is strongly authenticated Each node or IT system interfaced is strongly authenticated Each user shall be authenticated on the edge system Each user shall be authenticated on the edge system All traffic trough the infrastructure is encrypted All traffic trough the infrastructure is encrypted Patient consent needs multiple choices or levels Patient consent needs multiple choices or levels Unless opt-in, no data about a specific patient may be shared Unless opt-in, no data about a specific patient may be shared Several data sharing policies offered to the patient consent Several data sharing policies offered to the patient consent Each shared record/document is assigned to specific policies (or not shared) at encounter time. Each shared record/document is assigned to specific policies (or not shared) at encounter time. Healthcare providers may only access records/documents compatible with their role. Healthcare providers may only access records/documents compatible with their role.

32 32 Categories of Healthcare Communication Services Security Document Sharing Patient and Provider ID Mgt Dynamic Information Access Workflow Management Source-persisted and attested health records Specific info snapshot provided on demand 2 or more entities synchronize a task e.g. access to last 6 months historical labs and encounter summaries e.g. order a lab test, track status and receive results e.g. get a current list of allergies or med list from a source Hospitals HIEs and Shared EHRs

33 33 Categories of Healthcare Communication Services Security Document Sharing Patient and Provider ID Mgt Dynamic Information Access Workflow Management Source-persisted and attested health records Specific info snapshot provided on demand 2 or more entities synchronize a task e.g. access to last 6 months historical labs and encounter summaries e.g. order a lab test, track status and receive results e.g. get a current list of allergies or med list from a source Hospitals HIEs and Shared EHRs Cross-Enterprise Document Sharing (XDS) Patient Id Cross- Referencing (PIX) Medical Summary (XDS-MS)

34 34 IHE Profiles Specifications Go to: www.ihe.net/Technical_framework www.ihe.net/Technical_framework For XDS:Under IT Infrastructure E.g. IT Infrastructure Technical Framework (XDS.b) E.g. IT Infrastructure Technical Framework (XDS.b) For PIX:Under IT Infrastructure E.g. IT Infrastructure Technical Framework (PIX, HL7V2) E.g. IT Infrastructure Technical Framework (PIX, HL7V2) Or PIXV3 supplement (PIX HL7 V3). Or PIXV3 supplement (PIX HL7 V3). For XDS -MS: Under Patient Care Coordination E.g. PCC Technical framework (XDS-MS) E.g. PCC Technical framework (XDS-MS) For XDS-I: Under Patient Radiology E.g. RAD Technical framework (XDS-I) E.g. RAD Technical framework (XDS-I)

35 35 The IHE Global Standards Adoption Process First Step: Propose a Use case for Interoperability

36 36 Patient Identifier Cross-referencing for MPI Services Allow all enterprise participants to register the identifiers they use for patients in their domain Participants retain control over their own domains patient index(es) Support domain systems queries for mapping across other systems identifiers for their patients Optionally, notify domain systems when other systems update identifiers mapping for their patients

37 37 Patient Identifier Cross-referencing for MPI Value Proposition Maintain and linked 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 No need to force identifier and format changes onto existing systems Leverages standards and transactions already used within IHE

38 38 The IHE Global Standards Adoption Process Second Step: Propose a design and select standards for such an IHE Profile

39 39 Patient Identifier Cross-referencing for MPI Transaction Diagram

40 40 Patient Identifier Cross-referencing for MPI Process Flow Showing ID Domains & Transactions

41 41 Patient Identifier Cross-referencing for MPI B:X456 C: 2RT Identity Patient Cross References B:X456 C: ?

42 42 Patient Identifier Cross-referencing for MPI Actors Patient Identity Source Definition Definition Assigns patient identities within its own domain Assigns patient identities within its own domain Notifies Patient Identifier Cross-reference Manager of all events related to patient identification (creation, merge, etc.) Notifies Patient Identifier Cross-reference Manager of all events related to patient identification (creation, merge, etc.) Example: Registration (ADT) Actor in IHE Radiology Scheduled Workflow (SWF) Profile Example: Registration (ADT) Actor in IHE Radiology Scheduled Workflow (SWF) Profile Transaction Supported - Required Transaction Supported - Required Patient Identity Feed [ITI-8] (as sender) Patient Identity Feed [ITI-8] (as sender)

43 43 Patient Identifier Cross-referencing for MPI Actors Patient Identifier Cross-reference Consumer Definition Definition Requires information about patient identifiers in other domains Requires information about patient identifiers in other domains Requests patient identifier information from Patient Identifier Cross-reference Manager Requests patient identifier information from Patient Identifier Cross-reference Manager Transaction Supported - Required Transaction Supported - Required PIX Query [ITI-9] (as sender) PIX Query [ITI-9] (as sender) Transaction Supported - Optional Transaction Supported - Optional PIX Update Notification [ITI-10] (as receiver) PIX Update Notification [ITI-10] (as receiver)

44 44 Patient Identifier Cross-referencing for MPI Actors Patient Identifier Cross-reference Manager Definition Definition Serves a well-defined set of Patient Identifier Domains Serves a well-defined set of Patient Identifier Domains Receives patient identifier information from Patient Identity Source Actors Receives patient identifier information from Patient Identity Source Actors Manages cross-referencing of identifiers across domains Manages cross-referencing of identifiers across domains Transactions Supported - Required Transactions Supported - Required Patient Identity Feed [ITI-8] (as receiver) Patient Identity Feed [ITI-8] (as receiver) PIX Query [ITI-9] (as receiver) PIX Query [ITI-9] (as receiver) PIX Update Notification [ITI-10] (as sender) PIX Update Notification [ITI-10] (as sender)

45 45 Patient Identifier Cross-referencing for MPI Standards Used: 2 Profiles PIX: HL7 Version 2.5 ADT Registration and Update Trigger Events (HL7 2.3.1) ADT Registration and Update Trigger Events (HL7 2.3.1) A01: inpatient admission A01: inpatient admission A04: outpatient registration A04: outpatient registration A05: pre-admission A05: pre-admission A08: patient update A08: patient update A40: merge patient A40: merge patient Queries for Corresponding Identifiers (ADT^Q23/K23) Queries for Corresponding Identifiers (ADT^Q23/K23) Notification of Identifiers Lists Updates (ADT^A31) Notification of Identifiers Lists Updates (ADT^A31) PIX V3: HL7 V3 Leverage Web Services (harmonized WS by IHE Appendix V) Leverage Web Services (harmonized WS by IHE Appendix V)

46 46 The IHE Global Standards Adoption Process Third Step: Engage implementers for Testing Trial Implementation profile at Connectathons Fourth Step: Based on lessons learned from Connectathons implementers, correct/clarify Profile and Publish as Final Text in Domain Technical Framework. Will be presented in part 2 Will be presented in part 2

47 47 IHE offers a broad collection of Profiles Use Cases addressed are specified in a series of Domain Technical Frameworks (Volume 1) Two broad classes of profiles: Integration (how to move the data) and Content (what the data conveys). A few example of cross-enterprise integration and content profiles Complete list on: www.ihe.net/technical_framework www.ihe.net/technical_framework

48 48 Community Clinical Encounter Clinical IT System Health Info Exchange Clinic Record Specialist Record Hospital Record Registering Health Records:IHE-XDS 1-Reference to records Repository of Documents Index of patients records

49 49 Community Clinical Encounter Clinical IT System Aggregate Patient Info 4-Patient data presented to Physician HIE Clinic Record Specialist Record Hospital Record 2-Reference to Records for Inquiry Access to Shared Records : IHE-XDS 3-RecordsReturned Repository of Documents Index of patients records

50 50 Health Information Exchanges Interoperability: Cross-enterprise Document Sharing Cross-Enterprise Document Sharing simplifies clinical data management by defining interoperable infrastructure. Transparency = Ease of Evolution Patients have guaranteed portability and providers may share information without concerns of aggregation errors. Digital Documents = Patients and providers empowerment Supports both centralized and decentralized repository architectures. Ease of federation nationally. Flexible privacy, Flexibility of configurations Addresses the need for a longitudinal healthcare data (health records). Complements to interactive workflow or dynamic access to data.

51 51 Cross-Enterprise Document Sharing (XDS) Standards Used Healthcare Content Standards HL7 CDA header extract HL7 data types Internet Standards HTTP, IETF, W3C, … Electronic Business Standards ebXML Registry, SOAP, Web Services … Implemented world-wide by over 150 vendors/open source. Adopted in several national & regional projects: Italy, Austria, Canada, USA, Japan, South Africa, France, Netherlands, etc.)

52 52 Why is IHE-XDS a breakthrough ? It based on an International Standards; ebXML registry: OASIS and ISO standard, Web Service/Soap/XML. Sharing of digital documents as attested by the source, meets the most urgent needs. A proven healthcare community data-sharing paradigm ( Feeding a central web server is view only and hinders use of EHRs ). Efficient to support all types of Health IT Systems (IDNs, Hospitals, Ambulatory, Pharmacy, Diagnostics Centers, etc.) and all types of information (summaries, meds, images, lab reports, ECGs, etc.), structured and unstructured. Meets both the needs of push communication by info sources and on- demand pull in a variety of centralized or distributed architectures. Offer a consistent, standards-based and functional record sharing for EHRs, PHRs & other IT Systems

53 53 Combining IHE Profiles Document Content & Modes of Document Exchange Document Exchange Integration Profiles Document Sharing XDS / XCA Sharing XDS / XCA Media Interchange XDM Reliable Pt-Pt Interchange XDR Doc Content Profiles (Semantics content) Scanned Doc XDS-SD LaboratoryXD*-Lab PHR Exchange XPHR Discharge & Referrals XDS-MS ImagingXDS-I ConsentBPPCEmergencyEDR Pre- Surgery PPHP Functional Status Assesment FSA

54 54 Acute Care (Hospital) GPs and Clinics (Ambulatory) Long Term Care Other Specialized Care (incl. Diagnostics Services) Continuity of Care : Patient Longitudinal Record Typically, a patient goes through a sequence of encounters in different Care Settings

55 55 Acute Care (Inpatient) PCPs and Clinics (Ambulatory) Long Term Care Other Specialized Care or Diagnostics Services Building and accessing Documents Care Record systems supporting care delivery Documents Registry Document Repository Longitudinal Record as used across-encounters Submission of Document References Retrieve of selected Documents

56 56 Cross-Enterprise Document Sharing (XDS.b) Actor/Transaction Diagram

57 57 XDS – Value Proposition Foundation for Health IT Infrastructures: Shared Electronic Health Record, in a community, region, etc. Effective means to contribute and access clinical documents across health enterprises. Scalable sharing of documents between private physicians, clinics, long term care, pharmacy, acute care with different clinical IT systems. Easy access: Care providers are offered means to query and retrieve clinical documents of interest.

58 58 XDS - Value Proposition Distributed: Each Care delivery organization publishes clinical information for others. Actual documents may remain in the source EHR Cross-Enterprise: A Registry provides an index for published information to authorized care delivery organizations belonging to the same clinical affinity domain (e.g. a region). Document Centric: Published clinical data is organized into clinical documents. using agreed standard document types (HL7-CDA, PDF, DICOM, etc.) Document Content Neutral: Document content is processed only by source and consumer IT systems. Standardized Registry Attributes: Queries based on meaningful attributes ensure deterministic document searches.

59 59 How real is XDS ? Stable specification IHE Technical Framework Published XDS.b Supplement that offers: Use most recent Web Services stds (MTOM/XOP) Use most recent Web Services stds (MTOM/XOP) Allow Retrieve sets of Documents in one transaction Allow Retrieve sets of Documents in one transaction Same services Same services First implementation in clinical use in region of Genoa - Italy) since early 2006. Several since: Lower Austria region, State of Vermont, Nagoya city, South Africa region, Dutch regions, etc. Adopted by several national programs world-wide 4 open source toolkits available, numerous product implementations in EMRs and Infrastructure offerings.

60 60 IHE, Global Standards-Based Profiles Adopted in National & Regional Projects (sample) Quebec, Toronto, Alberta, British Columbia Canada Infoway THINC- New York NCHICA – N. Carolina Italy Conto Corrente Venetto - Friuli Boston Medical Center - MA Philadelphia HIE CHINA-MoH Lab results sharing CHINA-Shanghai Imaging Info Sharing JAPAN-Nagoya Imaging Info Sharing, Nationwide PDI guideline South Africa VITL-Vermont CareSpark – TN & VA NETHERLANDS Friesland Natnl Mamography Lower Austria France DMP Wales Imaging Belgium Flemish-Leuven Suisse St Gallen Lausane Providence Health System - OR KeyHIE Pennsylvania SHARP CA France Imaging IDF 60 For more complete list see: tinyurl.com/wwXDS

61 61 IHE-XDS is part of a family of profiles Regional, national, local or disease centric networks need a consistent set of Integration Profiles Fifthteen Integration Profiles completed and tested, plus five ready to implement = Standards-based interoperability building blocks for Rich Document Content for end-to-end application interoperability. Rich Document Content for end-to-end application interoperability. Patient identification management Patient identification management Security and privacy Security and privacy Notification and data capture Notification and data capture IHE-XDS + related IHE Integration profiles provide a complete interoperability solution

62 62 IHE Integration Profiles for Health Info Nets What is available and in trial implementation Emergency Referrals Format of the Document Content and associated coded vocabulary PHR Extracts/Updates Format of the Document Content and associated coded vocabulary ObGyn Documents Format of the Document Content and associated coded vocabulary Lab Results Document Content Format of the Document Content and associated coded vocabulary Scanned Documents Format of the Document Content Imaging Information Format of the Document Content and associated coded vocabulary Medical Summary ( Meds, Allergies, Pbs) Format of the Document Content and associated coded vocabulary Clinical and PHR Content Health Data Exchange Patient Demographics Query Patient Identifier Cross-referencing Map patient identifiers across independent identification domains Document Subscription and Notification Request Form for Data Capture External form with custom import/export scripting Patient ID Mgmt Other Final Text Approved Trial Implementation-2009– Final Txt 2010 Cross-Enterprise Document Sharing Registration, distribution and access across health enterprises of clinical documents forming a longitudinal record Cross-Enterprise Document Pt-Pt Reliable Interchange Cross-Enterprise Document Media Interchange Cross-Community Access Security & Privacy Consistent Time Coordinate time across networked systems Audit Trail & Node Authentication Centralized privacy audit trail and node to node authentication to create a secured domain. Basic Patients Privacy Consents Establish Consents & Enable Access Control Document Digital Signature Attesting true-copy and origin Cross-Enterprise User Assertion Provides Trusted Identity

63 63 XDS-MS and XPHR enable both semantic interoperability & simple viewing ! S S t t r r u u c c t t u u r r e e d d C C o o n n t t e e n n t t w w i i t t h h c c o o d d e e d d s s e e c c t t i i o o n n s s : : Reason for Referral Vital Signs M M e e d d i i c c a a t t i i o o n n Studies A A l l l l e e r r g g i i e e s s Social History P P r r o o b b l l e e m m s s Care Plan XDS-MS Medical Summary or PHR Extract Exchange Profile based on HL7 CDA Rel 2 and HL7 CCD IG Structured and Coded Header Patient, Author, Authenticator, Institution, Time of Service, etc. Header always structured and coded Title-coded sections with non-structured nor coded content (text, lists, tables). Simple Viewing (XML Style sheet) Level 1 Level 2 Text Structure Entry Text Structure Entry Med, Problems and Allergies as highly structured text. Text easy to import/parse Text Structure Entry Level 3 Med Problems and Allergies have a fine-grain structure with optional coding. Coding Scheme explicitly identified. Coded Section Entry Coded Section Entry Coded Section Entry Level 3

64 Content of the encounter Summary (IHE XDS-MS) Referral Summary (XDS- MS) Data Elements (1) Text Only or Text + Coded Reason for Referral History Present Illness Active Problems Current Meds Allergies History of Past Illness List of Surgeries Immunizations Family History Social History Pertinent Review of Systems Vital Signs Referral Summary (XDS- MS) Data Elements (2) Text Only or Text + Coded Physical Exam Relevant Diagnostic Surgical Procedures / Clinical Reports (including links) Relevant Diagnostic Test and Reports (Lab, Imaging, EKG's, etc.) including links. Plan of Care (new meds labs, or x-rays ordered) Advance Directives Patient Administrative Identifiers Pertinent Insurance Information Every Section title is coded

65 Content of discharge Summary (IHE XDS-MS) Discharge Summary (XDS- MS) Data Elements (1) Text Only or Text + Coded Date of Admission Date of Discharge Participating Providers and Roles Discharge Disposition (who, how, where) Admitting Diagnosis History of Present Illness Hospital Course Discharge Diagnosis (including active and resolved problems) Selected Medicine Administered during Hospitalization Discharge Summary (XDS-MS) Data Elements (2) Text Only or Text + Coded Allergies and adverse reactions Discharge Diet Review of Systems Vital Signs (most recent, high/low/average) Functional Status Relevant Procedures and Reports (including links) Relevant Diagnostic Tests and Reports (including links) Plan of Care Administrative Identifiers Pertinent Insurance Information Every Section title is coded

66 66 Use of a shared XDS infrastructure to access Radiology Reports and Images (XDS-I) Hospital Imaging Center Physician Practice Between Radiology and : Between Radiology and : Imaging specialistsImaging specialists Non-imaging cliniciansNon-imaging clinicians PACS B PACS A Radiology -to- Radiology Radiology -to- Physicians Same XDS Infrastructure (Registry and Repositories) for medical summaries and imaging information !

67 67 Sharing Radiology Reports and Images in a Regional Health Information Network Radiology Enterprise A Radiology Enterprise B Physician Office Regional Health Information Network Cross- Enterprise Registry Patient Id= 3547F45 Report 5/21/1998 : CT Head B Study 5/21/1998 : CT Head B Report 2/18/2005 : Chest Xray A Study 2/18/2005 : Chest Xray A PACS B PACS A

68 68 Physicians and Systems within a Regional Health Network - Routine Imaging Referral Radiology Enterprise A Radiology Enterprise B Physician Office Regional Health Information Network Query for Documents Register Imaging Information for sharing Prior imaging Reports & Studies Cross- Enterprise Registry Register Imaging Information for sharing Patient Id= 3547F45 Report 5/21/1998 : CT Head B Study 5/21/1998 : CT Head B

69 69 Physicians and Systems within a Regional Health Network - Routine Imaging Referral Radiology Enterprise A Radiology Enterprise B Physician Office Regional Health Information Network Register Imaging Information for sharing Cross- Enterprise Registry Notification of Doc Availability Register Imaging Information for sharing

70 70 Physicians and Systems within a Regional Health Network for a Routine Imaging Referral Radiology Enterprise A Radiology Enterprise B Physician Office Prior Imaging Report & Study Regional Health Information Network Query for documents Imaging Report & Study Cross- Enterprise Registry Patient Id= 3547F45 Report 5/21/1998 : CT Head B Study 5/21/1998 : CT Head B Report 2/18/2005 : Chest Xray A Study 2/18/2005 : Chest Xray A Notification of Doc Availability

71 71 XDS-I.b Dependencies XDS-I.b depends on IT Infrastructure Cross- Enterprise Document Sharing (XDS.b) Same Actors as in XDS Document Source Document Source Document Consumer Document Consumer Document Registry Document Registry Document Repository Document Repository Added extension to support imaging data (images and reports)

72 72 Document Consumer Retrieve Document Query Documents Patient Identity Source Patient Identity Feed Imaging Document Source Document Registry Document Repository Provide & Register Imaging Document Set Register Document Set XDS-I.b Actors and Transactions Retrieve Imaging Document Set Retrieve Presentation States Retrieve Key Image Note Retrieve Evidence Documents Retrieve Images & WADO

73 73 XDS-I Options Document Source must support at least one of the following options: Extensive Set of DICOM Instances Extensive Set of DICOM Instances PDF Report PDF Report Text Report Text Report Multipart Text/PDF Report Multipart Text/PDF Report

74 74 Sharing of Extensive DICOM Instance Set

75 75 Document Registry Document Repository Manifest Reference to image 1 DICOM Manifest Reference to image 2 Reference to image 3 Manifest Clinical Encounter Clinical IT System Query Registry Manifest Retrieve Manifest Reference to image 1 DICOM Manifest Reference to image 2 Reference to image 3 Retrieve ImagesRegister Manifest Manifest

76 76 Sharing of Extensive DICOM Instance Set The shared Document is a manifest a Key Object Selection DICOM Instance a Key Object Selection DICOM Instance Image Manager/Image Archive is required to ensure that the referenced images from within a published manifest are available to be retrieved to ensure that the referenced images from within a published manifest are available to be retrieved Document Source is responsible for replacing a previously submitted manifest Document when a change occurs to the manifest content (eg. Change of the DICOM SOP instances referenced within the manifest) for replacing a previously submitted manifest Document when a change occurs to the manifest content (eg. Change of the DICOM SOP instances referenced within the manifest)

77 77 Sharing of Imaging Report

78 78 Radiology system Report Source ….. Findings: Header : Report Type: OB / Gyn BPD... ….. Radiology Report Impressions : Gestational Age... Text Report PDF Report Text +PDF Report

79 79 Radiology system Report Source Document Registry Document Repository Report Clinical Encounter Clinical IT System Query Registry Retrieve ReportRegister Report Report ….. Findings: Header : Report Type: OB / Gyn BPD... ….. Radiology Report Impressions : Gestational Age...

80 80 Sharing of Report The shared Report Document format is PDF, Text, or multipart PDF + Text PDF, Text, or multipart PDF + Text A report can embed selected images in its PDF format embed selected images in its PDF format include fully resolved hyperlinks (interactively clickable) that point to the selected images include fully resolved hyperlinks (interactively clickable) that point to the selected images Document Source is responsible for formatting the hyperlink to reference relevant images as a DICOM WADO URI for formatting the hyperlink to reference relevant images as a DICOM WADO URI Document Source is required to ensure that image references are valid links to ensure that image references are valid links

81 81 Linking Report to Complete Set of Images Document Repository Document Registry Study Manifest Report Document Entry (Study Manifest) Document Entry (Imaging Report) Submission Set

82 82 Linking Report to Selected Images Radiology system Report Source ….. Findings: Header : Report Type: OB / Gyn BPD... ….. Radiology Report Relevant Image Gestational Age... WADO URI Link to image

83 83 XDS-I Metadata Radiology specific Acquisition Modality (e.g. CT, MR) Acquisition Modality (e.g. CT, MR) Anatomic Region (e.g. Arm, Elbow, Hand) Anatomic Region (e.g. Arm, Elbow, Hand) Requested procedure (e.g. MRI Knee with contrast) Requested procedure (e.g. MRI Knee with contrast) Query example find all CT of the Head of patient John Doe for the last 2 years find all CT of the Head of patient John Doe for the last 2 years

84 84 Providers and Vendors Working Together to Deliver Interoperable Health Information Systems And Across Care Settings Intra Hospital Workflows and Information Access Intra Hospital Workflows and Information Access http://www.ihe.net in the Enterprise

85 85 IHE Solutions within the Enterprise eMPI User Auth Enterprise IT Infrastructure Enterprise IT Infrastructure Laboratory LIS Auto Mgr Analyzer EMR - HIS Cardiology CIS CathECG Radiology RIS PACS Img Acq Eye Care Pathology Radiation Therapy Therapy Plan Img Acq Treatment Intensive Care Unit Nursing Station Devices Devices Home Hub Devices Pharmacy Established Feb 2009

86 86 IHE Solutions within the Enterprise Example: Cardiology eMPI User Auth Enterprise IT Infrastructure Enterprise IT Infrastructure Laboratory LIS Auto Mgr Analyzer EMR - HIS Cardiology CIS CathECG Radiology RIS PACS Img Acq Eye Care Pathology Radiation Therapy Therapy Plan Img Acq Treatment Intensive Care Unit Nursing Station Devices Devices Home Hub Devices Pharmacy Established Feb 2009 Cardiology Integration Profiles Cardiac Catheterization Lab Workflow Echocardiography Lab Workflow Retrieve ECG for Display Displayable Reports Cath and Echo Evidence Documents

87 87 IHE Solutions within the Enterprise Example: IT Infrastructure eMPI User Auth Enterprise IT Infrastructure Enterprise IT Infrastructure Laboratory LIS Auto Mgr Analyzer EMR - HIS Cardiology CIS CathECG Radiology RIS PACS Img Acq Eye Care Pathology Radiation Therapy Therapy Plan Img Acq Treatment Intensive Care Unit Nursing Station Devices Devices Home Hub Devices Pharmacy Established Feb 2009 IT Infrastructure Integration Profiles Patient Administration Management Patient Demographics Query Patient Identifier Cross-referencing Retrieve Information for Display Enterprise User Authentication Consistent Time Patient Synchronized Applications Audit Trail and Node Authentication Personnel White Pages Shared Value Sets

88 88 Patient Administration Mgt (PAM) Coordinates exchange of patient registrations, updates, and movements for all clinical areas Information may be received and processed by consuming 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 Standardizes on HL7 V2.5 and its conformance structures

89 89 Patient Administration Management Actor & Transaction: flexibility and compatibility Flexible Actor grouping

90 90 Patient Demographics Query – HL7 V2.5 Adopted b y HITSP Patient Demographics Supplier Patient Demographics Consumer Patient Demographics Query Patient Demographics and Visit Query Registration system or departmental system that is connected on demand to it. Diverse systems including bedside monitors, physician office systems, lab applications, mobile blood bank registries; might be any system at the point of care.

91 91 Patient Identifier Cross-referencing-HL7 V2.5 Adopted b y HITSP Registration system or eMPI Registration system Departmental or Outpatient system

92 92 IHE Solutions within the Enterprise Example: Radiology eMPI User Auth Enterprise IT Infrastructure Enterprise IT Infrastructure Laboratory LIS Auto Mgr Analyzer EMR - HIS Cardiology CIS CathECG Radiology RIS PACS Img Acq Eye Care Pathology Radiation Therapy Therapy Plan Img Acq Treatment Intensive Care Unit Nursing Station Devices Devices Home Hub Devices Pharmacy Established Feb 2009 Radiology Integration Profiles Radiology Scheduled Workflow Patient Information Reconciliation Access to Radiology Information Portable Data for Imaging Consistent Presentation of Images Key Image Note Presentation of Grouped Procedures Evidence Documents Audit trail and Node Authentication (Rad option) Teaching Files and Clinical Trials Export Post-processing Workflow Reporting Workflow Charge Posting Simple Image and Numeric Reports

93 93 Scheduled Workflow Profile Registration Orders Placed Orders Filled Film Folder Image Manager & Archive Film Lightbox report Report Repository Diagnostic Workstation Modality acquisition in-progress acquisition completed images printed Acquisition Modality

94 94 How the image is prepared: How it appears later: Grayscale Calibration & Presentation State Original Image Window Level Flip Zoom Area Of Interest Annotate Transformations Are Lost Original Image Area Of Interest Prepared Image Original Image Consistent Presentation of Images

95 95 Media Creator Printer [Media Reader] Image Display [Media Reader] PACS [Media Importer] John Doe CD DICOM Data Web Data (Optional) DICOM PC Browser Web Data Required to cleanup Patient ID, Acc#, etc. Portable Data for Imaging

96 96 IHE Solutions within the Enterprise Example: Laboratory eMPI User Auth Enterprise IT Infrastructure Enterprise IT Infrastructure Laboratory LIS Auto Mgr Analyzer EMR - HIS Cardiology CIS CathECG Radiology RIS PACS Img Acq Eye Care Pathology Radiation Therapy Therapy Plan Img Acq Treatment Intensive Care Unit Nursing Station Devices Devices Home Hub Devices Pharmacy Established Feb 2009 Laboratory Integration Profiles Laboratory Testing Workflow Laboratory Information Reconciliation Laboratory Point Of Care Testing Laboratory Device Automation Laboratory Code Set Distribution Laboratory BarCode

97 97 Laboratory Testing Workflow (LTW) & Laboratory Device Automation (LDA) Order FillerOrder Placer Order Result Tracker Placer order Filler order Results Work order LTW LDA Work Order Steps Query & download modes Analyzer Pre/post processor Automation Manager Tests results Profiles based on HL7 V2.5.1 Solid implementation experience

98 98 IHE Solutions within the Enterprise Example: Patient Care Devices eMPI User Auth Enterprise IT Infrastructure Enterprise IT Infrastructure Laboratory LIS Auto Mgr Analyzer EMR - HIS Cardiology CIS CathECG Radiology RIS PACS Img Acq Eye Care Pathology Radiation Therapy Therapy Plan Img Acq Treatment Intensive Care Unit Nursing Station Devices Devices Home Hub Personal Devices Pharmacy Established Feb 2009 Patient Care Devices Profiles Device Enterprise Communication (DEC) Alarm Communication Mgt (ACM) Subscribe to Patient Data (SPD) Patient Identity Binding (PIB) Rosetta Terminology Mapping (RTM)

99 99 Providers and Vendors Working Together to Deliver Interoperable Health Information Systems in the Enterprise and Across Care Settings http://www.ihe.net

100 100 Agenda Part 1: THE IHE STANDARDS ADOPTION PROCESS: achieving practical interoperability This Afternoon: Part 2: USERS AND VENDORS WORKING TOGETHER: how can I contribute & benefit from IHE HOW TO USE IHE RESOURCES: hands on experience

101 October 2010IHE Orientation-Cyprus 101 See you for Part 2, this afternoon


Download ppt "October 2010IHE Orientation-Cyprus 1 INTEGRATING THE HEALTHCARE ENTERPISE (IHE) Orientation Workshop TurkMIA Conference-10 Charles Parisot, IHE-Europe."

Similar presentations


Ads by Google