1 / 20

HL7 Road Shows March 2009 Carl Adler Integration Architect, WCI Healthcare

HL7 Case Study Lessons Learned Implementing Integrated Pathology and Radiology Requests & Results Reporting. HL7 Road Shows March 2009 Carl Adler Integration Architect, WCI Healthcare carl.adler@wcihealthcare.com. Agenda. Background Solution HL7 V2.x instead of V3 Lessons Learned

Download Presentation

HL7 Road Shows March 2009 Carl Adler Integration Architect, WCI Healthcare

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. HL7 Case StudyLessons Learned Implementing Integrated Pathology and Radiology Requests & Results Reporting HL7 Road Shows March 2009 Carl Adler Integration Architect, WCI Healthcare carl.adler@wcihealthcare.com

  2. Agenda • Background • Solution • HL7 V2.x instead of V3 • Lessons Learned • Role your own? • Q&A

  3. Background • Large London teaching hospitals trust • Approximately 2 Million Requests/Year (Path/Rad) (approx 700 requests/hour peak) • Live on R0 CRS • Pre CRS solution supported R&RR interfaces with WinPath and Rad Centre • Needed CRS PAS – R&RR integration

  4. Solution • There’s nothing “sexy” about integrated message based R&RR • But… without it all the romance of providing high quality patient care fizzles out • More error prone • Less efficient • Also, there’s nothing “sexy” about HL7 V2.x – but friendship usually is the best basis for a relationship

  5. Solution

  6. HL7 V2.3 versus V3? • There is a significant amount of activity around the world designing HL7 messages (e.g. CFH and HL7 itself) • HL7 V3 message designers and implementers are able to avail themselves of a world of XML tools • However, Path and Rad systems don’t yet support V3 Orders and Results Messages • ORM/ORU messages are largely mature and well understood The really important issues associated with integration are protocol independent

  7. Lessons Learned – The Really Big Issues • Workflow – Supporting the needs of differing departments and the Business • Defines the integration need and how interfaces are driven • Numbers (episode, accession, order, hospital, etc) • Reference Data • Varies everywhere – fact • Service Management – getting it going and keeping it going

  8. Workflow Analysis • This needs to be the first step in all integration projects: a request isn’t a request isn’t a request • Integration isn’t merely interfacing • Business and clinical processes determine integration requirements • Use Cases are a manifestation of those processes • Workflows are the expression of the use cases • Trigger events are generated during the execution of work flows

  9. Workflow Decomposition

  10. Workflow Analysis • HL7 helps because it is a mature standard and much of the information and rules is already covered. • But devil is in local detail • E.G. Microbiology different messaging solution to histology • E.G. Cancel • What does “cancel” an order mean? • When does/can/should it occur? • What impact does it have on the integration layer? • E.G. Cancel versus Discontinue (same questions)

  11. Workflow Analysis – Some Questions • Must a trust change its business to support its own integration requirements? • Are the business drivers for integration aligned with agreed best clinical practice? • For all disciplines? • Do compromises introduced in the design of the integration impact patient safety • This is really about error handling (or the lack of it)

  12. Numbers – Dynamic Identifiers • Every number generated by the PAS to identify some healthcare “thing” has a range, format and, even, sometimes a meaning • Systems communicating these numbers must agree on range, format and meaning • Examples: • Hospital Patient ID • Episode/Encounter number • Order ID • Accession Number

  13. Reference Data – Static Identifiers • Data about data (e.g. test names, “yes”/“no”, etc), typically a code and textual description • Regulatory Scope • National, Cluster and Local • Business process changes (i.e. changing the local name) • Mapping in the integration layer between local and national names • Reference data tied to business/clinical processes • E.G. Bone scan requires contrast media injection but injection isn’t a “Nuke Med” orderable on PAS • RIS catalogue includes injection; messages triggered within context of injection will fail to post on PAS

  14. Reference Data Management • Initial Synchronisation of PAS and downstream system • Test systems, test data and go-live transitions • Reference data updates • All systems must implement at the same time; or • Organisation must be prepared to deal with mismatches until all systems updated Reference data must be managed from the outset

  15. Service Management – Designing for Reliability • SLA’s • Interfaces fail – how quickly do we know? How quickly can we fix? • Queue lengths at peak times – affects delivery of messages • Clinical criticality • How do ordering physicians know order has been placed? • Solution management • Who monitors? • Who fixes? • How?

  16. Service Management – Designing for Reliability • Alerting • Which component “knows” something is wrong • What types of problems generate alerts? • Controlling alert overload • Where do alerts go? • Remedial actions • Simple – try resending • Reference data mismatch – fix and resend • Message corruption – usually source data related – cancel and retry after fixing • Message failure dependencies • What suffers when message fails?

  17. Service Management – Designing for Reliability • Fail safe designs • No such thing – don’t let the perfect get in the way of the good • E.G. map to a safe default if data supplied not in mapping table • End to end views • As much as possible each component is instrumented

  18. Roll Your Own? • Can you implement your own HL7 based integration • Yes, of course. But… • Know your integration requirements early • These sorts of projects can take on a life of their own • Sometimes it is better to outsource in order to ring-fence and share risk • If business practices have to change you can always blame “those damn consultants” • There are relatively few HL7 V2.x tools

  19. Conclusions • The administrative and clinical business of the hospital defines the requirements for integration • HL7 interfaces are one of the mechanisms for implementing integration • HL7 V2.x will exist – for foreseeable future • In order to integrate end-systems must share a common “understanding” of dynamic and static data • What can go wrong will – solution design must account for errors and error recovery • There are people out there who can make it a little easier

  20. Q&A Traditional scientific method has always been, at the very best, 20-20 hindsight. It's good for seeing where you've been. It's good for testing the truth of what you think you know, but it can't tell you where you ought to go Robert Pirsig – Zen and the Art of Motorcycle Maintenance

More Related