1 / 40

Implementing IHE in Regional Health Information Networks

2. Actors in Regional Healtcare. General Practitioners (GPs)Family DoctorsMedical SpecialistHospitalsEmergency Department (ED)Inpatient care, surgeriesHomecarePatient self-careNurses. 3. IHE Domains. CardiologyEye CareIT Infrastructuree.g. Cross-Enterprise Document Sharing (XDS)Laborator

alice
Download Presentation

Implementing IHE in Regional Health Information Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


    1. 1 Implementing IHE in Regional Health Information Networks May 17, 2007 Dan Russler, MD Oracle

    2. 2 Actors in Regional Healtcare General Practitioners (GPs) Family Doctors Medical Specialist Hospitals Emergency Department (ED) Inpatient care, surgeries Homecare Patient self-care Nurses

    3. 3 IHE Domains Cardiology Eye Care IT Infrastructure e.g. Cross-Enterprise Document Sharing (XDS) Laboratory Patient Care Coordination Patient Care Devices Radiology Mammography Nuclear Medicine

    4. 4 Patient Care Coordination The Patient Care Coordination (PCC) domain was established in July 2005 to deal with integration issues that cross providers, patient problems or time.

    5. 5 Profile Roadmap Year 2005-2006 (Trial Implementation) Medical Summary [MS] – Acute Care Discharge to PCP, PCP Referral to Specialist Unstructured Document – CDA-wrapped PDF Year 2006-2007 (Development & Testing) Medical Summary [MS] – ED Referral [EDR] Pre-procedure H&P [PPHP] Basic Patient Privacy Consents [BPPC] Exchange Personal Health Record [XPHR] Coordination with Laboratory Domain [XDS-LAB] Future (Profile Document / White Paper) Medical Summary [MS] – Discharge to LTC Forms Display for Data Capture (e.g. clinical research)

    6. 6 PCC Profiles

    7. 7 Medical Summary Profiles

    8. 8 Abstract Define a medical summary format for clinical documents containing at a minimum: Problems Allergies Medications Pointers to other material

    9. 9 Value Proposition Leverage Clinical Documents ontology A common mechanism for transfer of encoded clinical data embedded in documents Basis for ongoing harmonization of CCR/CCD Enhances Clinical Documents criteria for key use cases: Inpatient to Primary Care Provider Primary Care Provider to Specialist To be enhanced in future years to support: Home Care Long Term Care

    10. 10 Key Technical Properties Document Transfer (Integration Profile) XDS/XDP for document sharing. NAV for notification. XDS Folders to support organization. XDS Submission Sets to support packaging. Identification of “Master” document or Manifest Document Content (Content Profile) CDA Release 2.0 Care Record Summaries Implementation Guide

    11. 11 PCC Profiles

    12. 12 Use Case Health care provider determines that a patient needs to go to the ED Provider creates an ED referral package using his or her EHR Upon arrival, the ED provider identifies the patient as a referral The posted referral package is imported into the Emergency Department Information System (EDIS)

    13. 13 Value Proposition Nearly 5000 EDs in US Significant percentage of ED visits are referrals Shortage of critical health data for emergency department patients Need to improve communication of intended patient care plans to ED providers and ensure that no pertinent data is lost Streamline workflow by obviating telephone calls between busy clinicians

    14. 14 Scope EHR system capable of creating a care record summary would be capable of creating a referral package for a receiving system The emergency department information systems (EDIS) will need to retrieve and read and display this data.

    15. 15 PCC Profiles

    16. 16 Abstract The Basic Patient Privacy Consents (BPPC) profile provide mechanisms to: Record the patient privacy consent(s), Mark documents published to XDS with the patient privacy consent that was used to authorize the publication, Enforce the privacy consent appropriate to the use.

    17. 17 Scope Document Sources and Document Consumers in an XDS Affinity Domain Document Sources and Document Receivers using Cross Enterprise Point-to-Point Document Sharing

    18. 18 Value Proposition An Affinity Domain can develop privacy policies, and implement them with role-based or other access control mechanisms supported by EHR systems. A patient can Be made aware of an institutions privacy policies. Have an opportunity to selectively control access to their healthcare information.

    19. 19 Key Technical Properties Human Readable Consents Machine Processable Support for standards-based Role-Based Access Control

    20. 20 Standards and Profiles Used CDA Release 2.0 XDS Scanned Documents Document Digital Signature Cross Enterprise Document Sharing Cross Enterprise Point-to-Point Document Sharing

    21. 21 PCC Profiles

    22. 22 Use Case H&P documentation required prior to procedure that is designed to assess: Procedure Risk Anesthesia Risk Factors influencing procedure after-care decisions Desired outcomes Minimize injury during procedure Optimize procedure after-care

    23. 23 Scope To identify the required and optional PPHP document content templates including: CDA Document Header CDA Document Type(s) CDA Section Types CDA Entry Types

    24. 24 Value Proposition A procedure risk assessment must be present and evaluated by the operative and after-care teams before the patient is allowed to have the procedure. Missing information is frequently a reason for canceling the procedure for the day, which leads to expensive underutilization of resources and dissatisfied patients. Further, incomplete information about the patient’s clinical or home status may create a situation where a procedure is performed that ultimately results in an injury, inadequate aftercare or other undesirable outcome.

    25. 25 Key Technical Properties PPHP Profile inherits specifications required for other IHE PCC Medical Documents PPHP Profile follows documentation practices for all IHE PCC Medical Documents PPHP Profile emphasizes re-usability of CDA template identifiers in order to reduce un-necessary variability in IHE Content Profiles

    26. 26 Standards Used IHE Medical Document Content Profiles HL7 Reference Information Model ANSI Standard HL7 CDA R2 ANSI Standard HL7 Care Provision Domain DSTU (in process) Implementation Guides HL7 Care Record Summary CDA R2 Implementation Guide (in process) HL7/ASTM Continuity of Care Document Implementation Guide (in process)

    27. 27 PCC Profiles

    28. 28 Abstract The Exchange of Personal Health Record Content (XPHR) provides a standards-based specification for managing the interchange of documents between a Personal Health Record and an EHR System to enable better interoperability between these systems.

    29. 29 Scope Personal Health Record (PHR) Systems Electronic Health Record (EHR) Systems

    30. 30 Value Proposition Supports interchange of PHR Information Demographics Insurance Information Medications, Problems, Allergies Health History Other Information

    31. 31 Standards Used CDA Release 2.0 ASTM Continuity of Care (CCR) Data Set ASTM/HL7 Continuity of Care Document (CCD) HL7 Care Record Summary AHIMA PHR Common Data Elements XDS, XDP Document Digital Signature

    32. 32 Key Technical Properties Information is Human Readable and Machine Processable Support Static and Dynamic Information Sharing Domains (XDS and XDP) Protects Information using Digital Signature Update Model for EHR to PHR Changes

    33. 33 PCC Profiles

    34. 34 Scope The clinical laboratory report is: A report of a set of final results (the fulfillment process being completed) to be shared as “historical information”. Human-readable, shared between care providers of various specialties and patients (e.g. through a PHR) May contain machine readable coded entries (decision support, bio-surveillance) All clinical laboratory specialties in scope, except: Blood banks (blood products out of scope, but blood tests in scope) Pathology (has its dedicated domain in IHE) The clinical laboratory report is a final report that comes out after the fulfillment workflow has been achieved. It is intended first for human readers: care providers who will share this document within an electronic health record or a personal health record. It may contain fine grained coded data that can be integrated in the EHR or in the practitioner’s database. At this point in time, all clinical laboratory specialties are in scope except blood banks (this profile only addresses the blood bank testing like the report of an ABO group for a blood receiver) and pathology which manages different kinds of reports (mixing bulk text and large images). Pathology has its dedicated domain in IHE. The report uses CDA R2, constraining it with a set of templates at level 2 (human readable part) and level 3 (fine grained coded data).The clinical laboratory report is a final report that comes out after the fulfillment workflow has been achieved. It is intended first for human readers: care providers who will share this document within an electronic health record or a personal health record. It may contain fine grained coded data that can be integrated in the EHR or in the practitioner’s database. At this point in time, all clinical laboratory specialties are in scope except blood banks (this profile only addresses the blood bank testing like the report of an ABO group for a blood receiver) and pathology which manages different kinds of reports (mixing bulk text and large images). Pathology has its dedicated domain in IHE. The report uses CDA R2, constraining it with a set of templates at level 2 (human readable part) and level 3 (fine grained coded data).

    35. 35 Value Proposition Use case 1: Hospital lab report ? RHIO ? EHRs At discharge time, a hospital physician selects the most significant laboratory reports produced during patient stay, and issues these reports individually to a health information exchange (e.g. XDS Affinity Domain) shared by a number of healthcare enterprises and primary care providers. Use case 2: Ambulatory lab report ? RHIO ? PHR A private laboratory having signed a final report for a patient, sends this report in an electronic format to the patient record in the national EHR. Use case 3: Lab report ? PHR A physician reviews the results received from a reference laboratory for his patient. The doctor, as requested by the patient, sends this laboratory report in the patient’s personal health record in an electronic format. Use case 4: Lab report automatically shared ? RHIO A community or hospital laboratory, systematically (with some degree of automatism) shares its final reports with a regional healthcare network. Use case 5: Hospital’s EHR Lab report ? RHIO At discharge time of an inpatient, a hospital physician selects the most significant lab results, produced by one or more laboratories of the healthcare enterprise during patient stay, and builds a cumulative report sent to an health info exchange shared by a number of healthcare enterprises and primary care providers.

    36. 36 Standards Used CDA Release 2.0 ASTM/HL7 Continuity of Care Document (CCD) HL7 V3 Laboratory DMIM HL7 Care Record Summary LOINC & SNOMED HIPAA Lab Claim Attachment NPRM IHE XDS (registry/repository) & XDP (pt-pt) Document Digital Signature

    37. 37 Key Technical Properties Information is Human Readable (two levels of sections) and machine processable Full alignments with HL7 V3 lab messages Supports custom report organizations and results rendering regulations (e.g. CLIA in the USA). Complements the real-time result return to ordering provider (e.g. ELINCS). Used both in sharing (XDS) & pt-pt interchange (XDP) May protect Information using Digital Signature

    38. 38 PCC Wrap-up

    39. 39 PCC RoadMap Care Transfers Medical Summary 2005 EDR, PPHP 2006 Labs 2006-7 Growth Charts Consumer Empowerment PHR 2006 Consents 2006 Provider Ordering Ambulatory Ordering 2006 Medication Lists 2007 Clinical Data Reuse Clinical Trials (RFD) 2006-7 Biosurveillance 2007-8

    40. 40 As a Provider or Vendor Contributor Offer Clinical Use Case Input to Drive IHE Profile Development Become a member of relevant domain’s Planning or Technical Committees Become a member of relevant Regional/National Committees Help to shape IHE’s future direction As a Vendor Participant Respond to Public Comments of Domain Supplements Attend the Educational Workshops Participate in Connect-a-thons and Demonstrations As a Provider/Consultant Participant Respond to Public Comments of Domain Supplements Attend the Educational Workshops Attend Demonstrations and include IHE Integration Profiles in your RFPs and Integration Projects. How to Get Involved?

    41. 41 IHE Web Site - http://www.ihe.net Technical Frameworks Technical Framework Supplements – Trial Implementation Calls for Participation IHE Fact Sheet and FAQ IHE Integration Profiles: Guidelines for Buyers IHE Connectathon Results Vendors’ Product Integration Statements More Information

More Related