Enterprise Provider Directory Brian Postlethwaite Senior Solutions Architect HL7 International Patient Administration Co-chair HL7 International FHIR® Management Group Member Contributor to .NET FHIR® client

Agenda Healthcare Directories primer Our Enterprise Provider Directory Where is the FHIR®? Where are we going next? Before I get into the content, how many of you have a directory? And how many have multiple directories? Who has directory data problems?

Where are the Directories? Certification National Registration Regional Endpoints Enterprise Enterprise Enterprise Organization Organization Organization Application Application Application Application Application To understand the EPD better, it’s a good idea to have an understanding of where our product fits into the bigger picture of the Directories landscape. The deployment/distribution of directories The various levels have different levels of data, and with different usages ** Whether we like it or not, no directory in isolation can solve the problem, a solution that is able to manage the complexities of parent and child distributed content and manage this is key, and that is what we bring to the table. At the top, there is a LOT of records, but only a small amount of data about them, as we move done, we get less records, but they are more rich with local content. Then as we work along the bottom, information is needed across institutions…

Provider Directory vs Services Directory Organization Organization Location Practitioner Service Practitioner Locations as nested organizations Specialties/Services properties of locations/practitioners Duplicates details rather than share at the practitioner level Specialties/Services separated from practitioners Practitioners have different details at different locations Works without Practitioners! To understand why our application is structured the way it is, it is beneficial to understand the difference between a provider directory and a services directory, which is what our solution is. A Provider Directory is often derived from internal systems, not structured for various discovery search capabilities, and often a part of HR systems or security systems that serve a different purpose, tracking the person within an organizational hierarchy. These structures don’t really help searching, and struggle when you try and map services into the picture. And what about services where there is no practitioner listed (or even required)? This was the core profile built by IHE, and initially built on top of LDAP What problems are there with this?

Fundamentals for a successful directory Accurate Current Breadth of content Relevant terminology Accessible Minimal technical barriers Securely partitioned data Not just the details of the practitioners (as with your existing address book), its all the content that is needed for many uses, cut into the way that the users of the content want to see it. Anything that attends to these issues will improve your directory story. Performance is accessible, Curation mechanisms contribute to getting an accurate and current set of data (and Provenance can be used to see this)

Why are Directories in the Enterprise? Shared patient care Referrals Billing Imaging and Pathology ordering Prescribing Employment and accreditation Human Resources and Payroll Queue Management Systems … and many other systems/specialties … Internal & External Healthcare Providers have a complex mesh of information to be managed for: Connected systems: PAS – generally the primary source of provider information EMR (often EMR feeds from the PAS) Pharmacy Pathology Radiology Cardiology Endoscopy Queue management systems Private research databases HR and payroll

Using Directories in the Enterprise Typical Problems: Multiple disparate systems managing provider data Out of date and/or inconsistent data This leads to incomplete referrals/discharge summaries Misdirected information Delayed payments due to incorrect provider data Overheads in administering all the systems Various Identifiers, and Qualifications need tracking Practitioner and nurses with rotations every 6-12 months Benefits: Reduce overheads in administration Enhance clinical workflow Improved accuracy for clinical workflows/billing Quality and timeliness of care Electronic communication delivered to the correct place In and out of the enterprise Discharge/medication summaries Emergency Encounters Death notices Intake process: November graduation / results December register for an AHPRA number and internship January start at the hospital – have an AHPRA number, no provider number Internal doctors >100 Nurses >200 – have to renew every year, therefore track the annual renewal has been completed, must register per state Allied Health >60 Pharmacy >20 February provider numbers are issued to the X – to distribute the information to the wider system users 2nd year rotation for Dr’s mean a new provider number is required based on the site that they are working and the on boarding process begins again for >100 providers

Telstra Health – Enterprise Provider Directory Real-time Parent Data Source(s) Australian NHSD – (incl. National Identifiers) Additional Local Content Customizable Data/UI Content Moderation Exception Management Organization Enterprise Specific data/Identifiers Payroll support data Secure Messaging Identifiers/Details Realtime Outbound Data Feeds HL7 V2 (MFN) FHIR® REST Event Queue National Regional Registration Enterprise Organization Organization Centrally Directory content management and distribution application

EPD: Logical Architecture Diagram HL7v2 (msg) HL7 v2 Referrals System(s) PAS/CIS, Radiology… NHSD FHIR (pull) FHIR API (REST) Non HL7 v2 systems Integration Engine(s) Other data sync sources Event Queue FHIR (push) Reporting / Data Analytics .NET Implementation SQL Server Search Indexing Data (Solr) Supports integration engines, or native MLLP/File drop Planning to support FHIR subscriptions in the future (driven by our event queue) Also planning to cover bulk data import/export here

Capacity – Data Changes (since go-live)

Incoming Data needs cleaning Profile new properties Detect and resolve duplicates Define Moderation rules Clean source data (as best can be done) Needs to be done for each new system Clean target systems Our data services team provides specialist services in this space to ensure deployments and onboarding of new systems are as smooth as possible

Enterprise Provider Directory – Real Benefits Administration Benefits Reduction in manual data entry Content synchronised from parent directory Single point of entry/moderation Data shared to connected systems Reduces the time to onboard internal providers Appropriate subset of data sent to connected systems Point of Care Benefits Saves ~20 minutes during patient admission Removes the need to manually verify provider information (~124 calls per day) Improved communication with healthcare providers, so patients receive timely follow up care post discharge Able to locate practitioners/facilities to service a patients needs Timely processing of Lab results due to accurate addressing of electronic messaging Depending on the scale of the deployment, can save multiple EFTs on direct data administration, and who knows how much in the other indirect costs of not having correct data...

So where is the FHIR®?

FHIR® API Full feature FHIR® Server implementation Only Directory and Infrastructure resources Publicly tested Searching, chaining, includes Full Create, Read, Update, Delete Full Resource History Support FHIR Validation DSTU2 – STU3 (as read mirror) XML, json and html Smart on FHIR ® Security/OAuth Scopes

FHIR® Resources Core Data Model (DSTU2/STU3) Organization, Location, Practitioner, HealthcareService, PractitionerRole StructureDefinition Questionnaire/QuestionnaireResponse Terminology (ValueSet, CodeSystem) AuditEvent List (STU3 only) (STU3 is via shadow FHIR server) Organization Location Practitioner Role Practitioner Healthcare Service We use the Questionnaire Structures as the data entry system!

FHIR® Structure Definitions We chose FHIR as the native structures, as it gives such strong flexibility, yet with great profiling, validation and tooling support. We have simple extensibility built in, but permit using the more advanced standard tooling for creating more detailed information. http://sqlonfhir-aupd.azurewebsites.net/fhir/OperationOutcome/02bbf69a6af14d6296644510ec981f0b/_history/19?_format=html New version will have ability to load in external implementation guides complete – using this in STU3 to load the HL7 Australia base and Provider directory guide

FHIR® API - Validation FHIR json/xml valid (serialization) Core FHIR® profile validation, Australian and (Australian/local profiles too) Extended validation Item Types Extensions Custom validation OperationOutcome Content/messages appropriate to display to users

Telstra Health, SMD, NHSD, Futures (v4 API) NHSD (stu3) (ELS) EPD (dstu2) EPD (stu3) EPD (stu3) dstu2 -> stu3 Converter Augment data cc.com THSM SMD

FHIR® – EPD Coming Features Duplicate Management True FHIR® Subscriptions STU3 Edit & R4 Support Bulk Data Import and Export Endpoint management External Terminology Server integration Support the new IG Package format (npm)

Questions? https://www.youtube.com/watch?v=971-4LCrYVg