1. 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

2. 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?

3. 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…

4. 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?

5. 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)

6. 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

7. 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 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

8. 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

9. 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

10. Capacity – Data Changes (since go-live)

11. 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

12. 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...

13. So where is the FHIR®?

14. 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

15. 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!

16. 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.
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

17. 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

18. 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

19. 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)

20. Questions?