400 likes | 593 Views
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
E N D
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 ? PHRA 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 ? PHRA 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 ? RHIOA 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 ? RHIOAt 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