1 / 30

UHI Services Briefing SADI

UHI Services Briefing SADI. Andrew Young 19 February 2008. Agenda. Unique Identification Program Indicative Timeframes Business Process Scenarios. NEHTA: Shaping the future of healthcare. Set up and funded by Federal, State and Territory Governments as a separate and not-for-profit entity

jemima-bowman
Download Presentation

UHI Services Briefing SADI

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. UHI Services BriefingSADI Andrew Young 19 February 2008

  2. Agenda Unique Identification Program Indicative Timeframes Business Process Scenarios

  3. NEHTA: Shaping the future of healthcare • Set up and funded by Federal, State and Territory Governments as a separate and not-for-profit entity • Facilitate and progress e-health for Australia • Board comprises heads of health departments in all jurisdictions

  4. Shaping the future of healthcare E-health will start with the following common communication areas: • Pathology • Discharge summaries • Referrals • Medication management • Clinical terminology • Unique identification

  5. Unique Identification: UHI Services • Nationally manage identification in the health sector to enable e-health communication • Allocate, issue and maintain health IDs for: • Patients • Healthcare Providers • Healthcare organisations • Create a national Healthcare Provider Directory Service

  6. Health Identifiers • Three identifiers: • IHI: Individual Healthcare Identifier for Individuals • HPI-I: Healthcare Provider Identifier for Individuals • HPI-O: Healthcare Provider Identifier for Organisations

  7. Patient Identifier - IHI • A number • Demographic information: • Identification details, i.e. name, date of birth, sex • Communication details, i.e. address, telephone number • No clinical information will be contained in the identifier

  8. Provider Identifier – HPI-I • A number • Professional information • Personal details, i.e. name, sex, date of birth • Professional details, i.e. specialty, work address, work contact details

  9. Healthcare Organisation Identifier – HPI-O • A number • Organisation information: • Organisation details, i.e. name, address, type of organisation, ACN, specialties • Organisation communication details, i.e. phone number, fax number, e mail address

  10. IHI HPI-O Electronic Health Record Who for Where Patient Healthcare Event Healthcare Provider - Organisation Who by HPI-I Healthcare Provider - Individual Describing a Healthcare Event - EHR • The IHI, HPI-I and HPI-O provide a nationally standardised set of identifiers that can be used for describing the • Recipient of a health service – the IHI • Individual that provided the service – the HPI-I • Where the service was provided – the HPI-O

  11. UHI Services – Approach Leveraging Medicare Australia National centralised approach NEHTA will work with stakeholders to promote adoption and uptake of UHI Services Progressive adoption and uptake

  12. Key Design Elements Initial IHI data from Medicare CDMS covering 99% of the Australian population Opt-in model for use of identifiers HPI-I data sourced from: Medicare Australia provider directory service (PDS) Registration boards

  13. Scope In scope HPI-I token Design and build of UHI Services Notification of IHI to individuals Consent framework Out of Scope IHI token Stakeholder software/modifications Stakeholder interface development Marketing of UHI Services

  14. Indicative Timeframes Jan 2008: Privacy impact assessment Jun 2008: Jurisdiction impact assessment July 2008: Complete final design Dec 2008: Complete system build and functional testing Mar 2009: Complete user acceptance testing phase 1 Jun 2009: Complete web services design Dec 2009: Complete user acceptance testing phase 2 Jan 2010: System operational

  15. Scenario: Establish ‘seed’ HPI-O Context: A healthcare facility needs to establish an HPI-O. This HPI-O will be the ‘seed’ HPI-O for an entity. HPI-O identifiers for facilities within that entity will be associated with it. HPI-O (LegalRepresentative) Provides evidence of Legal Entity & ability to act on its behalf Receives User Account details HPI-O established “Create Maintenance Role” Local System UHI Service Operator (Service Operator) Service Provider‘Front Office’ (e.g. Medicare Office) Creates SeedHPI-O request  HPI Service (system) Creates HPI-O Flags HPI-O as Active Notifies Legal Representative’s User Account  The interaction between the Legal Representative and the UHI Services will be supported by Medicare Australia channels and web services

  16. Scenario: Establish HPI-O Maintenance Role Context: A ‘seed’ HPI-O has been created by the Legal Representative. An ‘Organisation Maintenance Role’ needs to be established to perform ongoing maintenance of the HPI-O information HPI-O (LegalRepresentative) Prepares Org. Maintenance Role request Organisation Maintenance Role Established Established HPI-O Local System Requests create Org. Maintenance Role Notifies creation of Organisation Maintenance Role  Healthcare Facility (OrganisationMaintenance Role) Receives UHI User Account details LocalSystem UHI Service Operator (Service Operator) HPI Service (System) Creates Organisation Maintenance Role Notifies creation of Organisation Maintenance Role Notifies Org. Maintenance User Account  The interaction between the Legal Representative and the UHI Services will be supported by Medicare Australia channels and web services

  17. Scenario: Maintain HPI-O Context: Changes are needed to the information stored in the UHI Services about the HPI-O HealthcareFacility (OrganisationMaintenanceRole) Creates Update HPI-O Record request HPI-O update required HPI-O update Complete  Sends Update HPI-O Record request Notifies of updated HPI-O LocalSystem UHI Service Operator (Service Operator) Service Provider‘Front Office’ (e.g. Medicare Office) HPI Service (System) Applies requested updates Notifies of updated HPI-O  The interaction between the Legal Representative and the UHI Services will be supported by Medicare Australia channels and web services

  18. Scenario: Create HPI-I Context: An HPI-I needs to be established for a healthcare provider Pathologist (as HealthcareProviderIndividual) Provides requested information to be registered as a Pathologist Provides informed consent to participate in the UHI Program HPI-I creation Complete RegistrationBoard (Trusted Data Source) Creates HPI-I request Notifies of created HPI-I Local System Expected that registration board system will participate UHI Service Operator (Service Operator) HPI Service (system) Creates HPI-I Flags HPI-I as active Notifies of created HPI-I

  19. Scenario: Establish HPI-I Relationship with HPI-O Context: An HPI-I has entered into an employment or contractual relationship with an HPI-O IndividualHealthcare Provider (HPI-I,e.g. Pathologist, Specialist) HPI-I takes job with HPI-O HPI-I – HPI-O relationship established Healthcare Facility (Organisation MaintenanceRole) Defines HPI-I and HPI-O relationship Notifies of registered relationship LocalSystem Requests HPI-O & HPI-I relationship be established Notifies of registered relationship UHI Service Provider Directory UHI Service Operator (Service Operator) HPI Service (system) RegistersHPI-I – HPI-O relationship Creates entry in UHI Provider Directory Notifies of registered relationship

  20. Scenario: Retire IHI or HPI-I Births, Deaths& Marriages (Reference Data Source) Sends set of data UHI ServiceOperator (Service Operator) IHI, HPIService (system) Requests set of data Notifies Service Operator of received information Flags IHI/HPI-I as Retired Scheduled event COMPLETE Action required No action required

  21. Data Fields – HPI-I

  22. Data Fields – HPI-I (cont’d)

  23. Data Fields – HPI-I (cont’d)

  24. Data Fields – HPI-O

  25. Data Fields – HPI-O (cont’d)

  26. Technical Requirements • Web browser based user interfaces • Internet • Implementation of Service Oriented Architecture (SOA) • Implementation of Service Technologies to enable interaction between existing local systems and the UHI Services

  27. Technical Requirements (cont’d) • Support for web services and messaging protocol standards, e.g. SOAP and HL7 • Multiple mechanisms for information delivery, e.g. real time, batch, or one way file transfers • Implementation of Single Sign On • 24/7 system availability

  28. Data Quality • Data Quality Framework • Automated data quality tools to detect, clean and monitory IHI and HPI information • Quality assurance, control and audit • Issue management for UHI Services build and operation • Continuous improvement program • Data quality reporting

  29. Standards • ISO 7812 - Identification Cards –Identification of Issues • ISO PDTS 22220 - Health informatics - Identification of subjects of healthcare • AS 5017 - Healthcare Client Identification • AS 4846 - Healthcare Provider Identification • HL7

  30. Questions? Andrew Young - UHI Relationship Manager Amber Creswell - UHI Jurisdiction Liaison Officer Liliana Herrera - UHI Business Analyst

More Related