Your SlideShare is downloading. ×
0
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Antonio Abbenante   interoperability from the beginning to the end
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Antonio Abbenante interoperability from the beginning to the end

172

Published on

Antonio Abbenante delivered the presentation at the 2013 eHealth Interoperability Conference. …

Antonio Abbenante delivered the presentation at the 2013 eHealth Interoperability Conference.

The 2013 eHealth Interoperability Conference program is a balance between updates on state-wide interoperability projects, health service eHealth project case studies, and discussions of overarching principles such as information governance, data standardisation, and the future direction of eHealth in Australasia.

For more information about the event, please visit: http://www.informa.com.au/eHealth13

eHealth13, healthcare, eHealth, informahealthcare, informa, interoperability, health service, information standardisation, medicines data, public hospital, hospital, technology transparency, patient care, healthcare record, electronic health record

Published in: Health & Medicine, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
172
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. This image cannot currently be displayed. Interoperability: From the Beginning to the End Tony Abbenante Manager Health Design Authority and Integration Office of the Chief Information Officer Department of Health - Victoria
  • 2. My Background State-wide and national health IT solutions and interoperability: • 25 years of experience in health IT solutions, acute care, community care, national initiatives • Predominantly in Australia, USA, Malaysia, Singapore • Application design, development and implementation of key healthcare systems Clinical Systems, Costing Systems, PAS, Radiology, Pathology, Emergency, Scheduling, Theatre, Pharmacy, etc. • Application integration or integration design of almost every healthcare system Clinical Systems, Costing Systems, Patient Administration Systems, Radiology, Pathology, Emergency, Scheduling, Theatre, Pharmacy, National eHealth Systems (PCEHR, IHI, etc.) • National Standards for messaging, NEHTA packages Input and adoption • Currently: Manager of the Heath Design Authority for Department of Health Victoria http://www.health.vic.gov.au/designauthority/
  • 3. The Beginning to the End The journey: • The elements of interoperability and integration • Case Study Electronic Medications Management; a business re-design exercise • Key lessons, principles and practice • The Victorian Approach The future of interoperability in Victoria
  • 4. Interoperability and Integration What is the definition of interoperability? “There are two parts to the definition of interoperability: 1) The ability of two or more systems to exchange information. 2) The ability of those systems to use the information that has been exchanged. This means that health information exchange is different than health information interoperability. Exchange is a necessary for interoperability, but it is not sufficient by itself to achieve health information interoperability.” (Fridsma, D. 2013)
  • 5. Interoperability and Integration What is the definition of interoperability? • The capability to share a common functional capability across two or more software applications A patient registration replicated from a Patient Administration System to an Emergency Department System A pathology order from an Electronic Medical Record (EMR) System to a Pathology System A pathology result from a Pathology System to an EMR A discharge summary interface from an EMR to the Personally Controlled Electronic Health Record (PCEHR)
  • 6. Interoperability and Integration To be “Best of Breed” or not? “Gartner recommends that, whenever possible, Healthcare Delivery Organisations should favour truly integrated applications where complex structured clinical detail must match in every detail or the workflow passed between the two applications very frequently”. “The need to avoid as much as possible interfacing applications, and not to embrace a “best of breed” model as a first choice for clinical systems or other highly complex enterprise applications, as this compromises the practice of evidence based medicine”. (Rishel, 2010), (Handler, 2011) • The Cycle of Interoperability and application adoption Has almost gone full circle. In the 90’s, many of the application functions were integrated in one In the 2000’s, we adopted a best of breed approach Now, we are heading to a solution design approach, centralised for core functions, typically centered around the EMR or Clinical System
  • 7. Interoperability and Integration To be “Best of Breed” or not? • Well it depends on what you want to do: Within a Health Service (Capability) - Do you want a high level of active decision support? Drug to drug, drug to allergy, over prescription interaction checking (Capability) - Do you want to manage duplicate diagnostic orders and warn clinicians? (Benefit) – Reduce patient length of stay (Benefit) – Reduce adverse events • Well it depends on what you want to do: External to a Health Service Sending a discharge summary to a General Practitioner A pathology result from a Pathology System to an EMR A discharge summary interface from an EMR to the Personally Controlled Electronic Health Record (PCEHR)
  • 8. Interoperability and Integration How do we communicate? Would you like to go the footy on Saturday? I suppose, who is playing? Richmond and Carlton What time is the game? 2.00pm I suppose we will need to meet there a bit earlier Yes, should meet at 1.30pm, it will be busy Where shall we meet? How about Gate 3, do know where that is? Roughly, should be able to find it Who is going to take care of the kids?
  • 9. Interoperability and Integration How does an interface work? • Human interoperability is achieved by interrogation until an understanding is achieved. Even then there are still interpretations Are they going out to dinner afterwards? • Every one of you probably has a different perception of that conversation • Interoperability turns a human conversation upside down. Interfaces assume a predetermined result and works backwards from that • An interface can typically only have one very specific purpose and outcome when it is actioned • The purpose needs to be very clear
  • 10. Interoperability and Integration How does an interface work? (register a patient) Patient Administration System Emergency System Semantic Meaning Terminology 1:Male 2:Female Network Business Process Change Integratio n Engine
  • 11. Interoperability and Integration How does an interface really work? • Business process flows across the organisation: Solution view • Change in processes: Change management How does this impact the medical records department? What is the central registration point? • Terminology alignment • Governance: Terminology, policy, ongoing conformance and compliance • Testing: User, system integration unit • Data migration • Application enhancements • Transporting data • Ongoing support, ongoing solution design
  • 12. Case Study - eMM Electronic Medications Management: • What we wanted to achieve Closed loop electronic inpatient medications – no paper chart Medication reconciliation, on admission and discharge Electronic orders for medications – emergency, inpatient and outpatient, PBS Reduce adverse events – medication errors or other – strong clinical decision support
  • 13. Case Study - eMM Electronic Medications Management: • We are all solution designers At a high level, you would assume that this is an interoperability solution from the EMR to Pharmacy This is an interoperability solution across the enterprise: o Alerts and Allergy re-design is required across the enterprise o Terminology needs to be reviewed and re-designed o Decision Support requires re-design, medication processes to be reviewed o This has impacted change at a minimum to the following applications: • Patient Administration Systems, Clinical Systems • Emergency Systems, HR systems, ICU, Oncology • Scheduling Systems, Diagnostic Systems • Nurse Management Systems, Scanning Systems • Most Specialty Systems
  • 14. Case Study - eMM Electronic Medications Management: • How did we go about it? Key solution and process elements What is the organisation’s Clinical Decisions Support (CDS) approach? Active or Passive? What is the organisation’s Alert and Allergy approach? Clinical or Administrative? • How did we go about it? Key principles tied to outcomes or benefits were defined and agreed with Stakeholders • National Standards to be used for CDS and Terminology (AMT and SNOMED) • Active Decision Support required for medication errors. This drove the following principles Medication Orders will only be initiated from the EMR (Clinical System) Clinical Alerts and Allergies initiated and managed from the EMR – major change in thinking Primary Active Clinical Decision Support will be centered in the EMR
  • 15. Case Study - eMM Medications Functions Prescribing - Inpatient, discharge, outpatient PBS prescription validation Medications administration Basic reporting - Discharge, current medications Associated Clinical System Functions View pathology and imaging results Patient clinical information - Allergies, alerts, problems, weight, etc. Decision support - Interactions, dose range checking - Clinical protocols Pharmacy (Inpatient and Retail) Functions Provider override review Pharmacist validation Product assignment Basic reporting RDE Pharmacy Encoded Order Electronic Medications Management: • How did we go about it? Solution design stakeholders and vendors 12 month design process was anticipated and required Functional model with pharmacists: HDA guided the process, measured against principles and benefits Health Service Pharmacy System Medications dispensing Limited decision support (interactions, allergies) Inventory control Purchasing PBS claiming Pharmacy reporting Health Service Pharmacy System Medications dispensing Limited decision support (interactions, allergies) Inventory control Purchasing PBS claiming Pharmacy reporting
  • 16. Case Study - eMM Electronic Medications Management: • How did we go about it? Solution design stakeholders and vendors 12 month design process was anticipated and required Functional model with pharmacists: HDA guided the process, measured against principles and benefits Models socialised with clinicians and pharmacy vendors for feasibility and functional/technical design. This informed the Business Requirement Changes for vendors Key business processes reviewed in workshops with clinicians, pharmacists and vendors. This informed detailed Product Requirement Changes for vendors
  • 17. Case Study - eMM Electronic Medications Management - 50 scenarios (example): 1. MEDICATION ORDERS SCENARIO ANALYSIS……………………………………………………… 1.1 SCENARIO – INPATIENTS, NEW MEDS FOR DISPENSE……………………………………… 1.2 SCENARIO – INPATIENTS, NEW MEDS FROM IMPREST……………………………………... 1.3 SCENARIO – INPATIENTS, PRODUCT AUTO-ASSIGNMENT AND AUTO-VERIFICATION, PRODUCT DISPENSED IN PHARMACY………………………….................................................... 1.4 SCENARIO – INPATIENTS, PRODUCT AUTO-ASSIGNMENT AND AUTO-VERIFICATION, PRODUCT DISPENSED IN IMPREST………………………………………………………………….. 1.5 SCENARIO – INPATIENTS, S100/AUTHORITY PRODUCT DISPENSED IN PHARMACY…. 1.6 SCENARIO – INPATIENTS, SAS PRODUCT DISPENSED IN PHARMACY………………..… 1.7 SCENARIO – INPATIENTS, FREE TEXT (EXTEMPORANEOUS) PRODUCT DISPENSED IN PHARMACY………………………………………...…………………………………………………… 1.8 SCENARIO – INPATIENTS, CLINICAL TRIALS PRODUCT DISPENSED IN PHARMACY…... 1.9 SCENARIO – INPATIENTS, COMBINATION PRODUCT DISPENSED IN PHARMACY…...…. 1.10 SCENARIO – INPATIENTS, BRAND LEVEL (TPP) PRODUCT DISPENSED IN PHARMACY…………………………………………………………………………………...................... 1.11 SCENARIO – OUTPATIENT/DISCHARGE MEDS, PBS PRODUCT DISPENSED IN PHARMACY (PATIENT TO COLLECT MEDS FROM THERE……………………………..………….. 1.12 SCENARIO – OUPATIENT/DISCHARGE MEDS, PBS PRODUCT NOT DISPENSED IN PHARMACY (PATIENT TO GET PRESCRIPTION FILLED IN COMMUNITY ………………………. 1.13 SCENARIO – OUTPATIENT/DISCHARGE MEDS, PBS PRODUCT WITH “NO BRAND SUBSTITUTION” FLAGGED, DISPENSED IN PHARMACY……………………………………………
  • 18. Case Study - eMM Electronic Medications Management: • How did we go about it? Solution design stakeholders and vendors 12 month design process was anticipated and required Functional model with pharmacists: HDA guided the process, measured against principles and benefits Models socialised with clinicians and pharmacy vendors for feasibility and functional/technical design. This informed the Business Requirement Changes for vendors Key business processes reviewed in workshops with clinicians, pharmacists and vendors. This informed detailed Product Requirement Changes for vendors This completes high level design Change management defined from this Technical interface followed this
  • 19. Case Study - eMM Electronic Medications Management: • Key points The HDA facilitated design process, principles and set solution boundaries Principles agreed with stakeholders, not the design Vendors were involved in the process right through and provided insight on capability and feasibility Vendors were provided with clinician and pharmacist views on key directions for the future in Victoria Pharmacists and clinicians drove and defined functional requirements Every party had ownership. There were no surprises
  • 20. Solution & Business Design Change Management Technical Design and Build Testing Maintenance Ongoing Change Case Study - eMM Electronic Medications Management - effort and cost: • Note, technical design and build is the smallest component • This is, however, the focus of our estimations
  • 21. Key Lessons Principles and Practice Product selection: • Don’t pick a product on individual merits. Assess the merits against the merits that fit the solution elements and principles of the organisation as a whole • Is the organisation heading toward HIMSS level 7? • Sometimes small losses in functionality provide significant overall gains • Does the product build the overall vision? • Terminology, key enterprise functions, CDS • Top down design, not bottom up
  • 22. Key Lessons Principles and Practice Product selection: • Round hole, square peg • Vendors don’t understand your environment • Common systems/concepts that challenge this Emergency Department Systems Pharmacy Systems Enterprising Scheduling Diagnostic Systems Distributed CDS, CPOE
  • 23. Key Lessons Principles and Practice Interoperability across organisations vs internal to an organisation: • Very different principles apply • Very different benefits apply e.g. Continuity of Care benefits • Very different design and functional capabilities apply e.g. Limited CDS Integrate when you can, don’t interface: • Interfaces always reduce functional capability
  • 24. Key Lessons Principles and Practice Select the master system for each function in your environment: • e.g. Two systems performing patient registration is not good practice and does not work • Select the master for each key function; CDS from EMR, patient registration from PAS, etc. Interoperability is a key requirement: • Interfacing is unavoidable and is almost always required typically via an integration engine
  • 25. Key Lessons Principles and Practice Interoperability requires strong distributed governance: • Terminology consistent across applications • Conformance and compliance process Information technology projects need strong sponsorship: • Key stakeholder must be involved as required Clinicians, Nursing, Executive Directors, etc. • Victorian EMR implementations have adopted CMIOs fully allocated to the project • Project resources should be fully allocated to do two jobs
  • 26. Key Lessons Principles and Practice Vendor relationships – as per Medications Case Study: • Ongoing communication From inception • Change management approach • Clear vision of direction and interoperability standards • Time to adopt and change Localising standards – guide to use of standards in Victoria: • There are many standards. Need to choose the standards that suit your environment, reporting requirement. Lead toward future vision and national directions • Local guide for implementation e.g. Use Australian Standards and determine local use (HDA web page) • Underpinned by Government Policy and Funding Guidelines • Aligned with Government Quality Assurance Processes
  • 27. Interoperability in Victoria – Beginning to End Health Design Authority StrategyStrategy Plan and Design Plan and Design BuildBuildImplementImplement Govern and SustainGovern and Sustain Strategy: • Health Design Authority Strategy and approach Overall design responsibility, interoperability and health application solution design Interoperability and standards Interoperability framework Set and monitor design principles • Strategy and vision Significant focus in last 2 years enabled via Health Design Forum using Active approach
  • 28. Interoperability in Victoria – Beginning to End Health Design Authority StrategyStrategy Plan and Design Plan and Design BuildBuildImplementImplement Govern and SustainGovern and Sustain Strategy - Active: • Environment Independent health services Variety of health applications Governed by interoperability standards National and local initiatives • Vision Health Design Forum – sector Design Authority and DH • Artifacts International and local research Interoperability framework Standards Benefits, vision
  • 29. Interoperability in Victoria – Beginning to End Health Design Authority Strategy – Health Design Forum: • Health sector representation • International representation (Gartner) • DH representation • Combined research (DH & Gartner) • Jurisdiction representation • Research, knowledge and direction • Topics Continuity of Care EMR Adoption Medications Management Benefits, Change and Adoption etc. Investigate Assess ApproveCommunicate
  • 30. Interoperability in Victoria – Beginning to End Health Design Authority StrategyStrategy Plan and Design Plan and Design BuildBuildImplementImplement Govern and SustainGovern and Sustain Govern and Sustain: • Future introduction of conformance processes • Anticipated to be in the form of vendor accreditation to Victorian interoperability standards usage • DH funding and Policy Guidelines sets direction and funding requirements via Quality Assurance for ongoing funding and tenders
  • 31. Interoperability in Victoria – Beginning to End Health Design Authority StrategyStrategy Plan and Design Plan and Design BuildBuildImplementImplement Govern and SustainGovern and Sustain Questions?

×