1. Perspectives on Assessments: Health Indicators in PHIN Certification
Planning for PHIN Certification: A Small State’s Experience New Hampshire DHHS HLN Consulting, LLC®
PHIN Conference 2008
Perspectives on Assessments: Health Indicators in PHIN Certification
August 26, 2008

2. Agenda Background Project Scope Approach Narrative
System Inventory Database
Findings and Roadmap
4/20/2019

3. Background
In the spring of 2008, the State of New Hampshire Department of Health and Human Services (DHHS) partnered with HLN Consulting, LLC (HLN) to study the current level of compliance with PHIN 2.0 requirements.
The primary objective of this project was to deliver a gap analysis for PHIN compliance, and a roadmap for the State to begin to close that gap.
4/20/2019

4. Project Scope
Goal: Develop a gap analysis for PHIN compliance and a roadmap to begin closing the gap
Strategic approach: High-level principles and security strategies
and
Tactical approach: Specific systems recommendations
Challenge: PHIN requirements represent a “moving target”
4/20/2019

5. Remember PHIN “1.0”? Six Functional Areas Early Event Detection
Outbreak Management
Connecting Laboratory Systems
Countermeasure and Response Administration
Partner Communication and Alerting
Cross-Functional Components
Message construction, routing, transport, parsing; Directory; OID; vocabulary, data model, security
4/20/2019

6. PHIN 2.0 Reorganize – simplify – consolidate
Focus on messaging, directory, security
Expand scope beyond preparedness
5 PHIN Requirements
Message Composition
Message Send
Message Receive
Directory Services
Security
PHIN Certifications – work in progress
Notification messages to CDC, Alerting, Directory
4/20/2019

7. PHIN & Project Scope – Approach
Project is “Not just about PHIN”
Develop cross-functional architecture principles and priorities – shared services; person matching, reporting, AAA, vocabulary, messaging, etc.
Not all requirements receive same focus
For example – #5 Security – leverage OIT strengths
PHIN Certifications are “moving target” – develop guidelines/standards to anticipate
4/20/2019

8. High-level Approach
4/20/2019

9. Participation Plan
Governance
Structure
4/20/2019

10. Project Phases Initial Information Gathering
Key Tasks
Initial Information Gathering
Develop Gap Analysis Methodology and Tools
Conduct Review/Gap Analysis
Develop Options and Recommendations
Infrastructure/Architecture
Systems
4/20/2019

11. Project Phases Initial Information Gathering
Key Tasks
Initial Information Gathering
Develop Gap Analysis Methodology and Tools
Conduct Review/Gap Analysis
Develop Options and Recommendations
Infrastructure/Architecture
Systems
4/20/2019

12. System Inventory Database
Web-based system inventory application developed and customized for this project
Interview tracking
System list
Gap Analysis tool
Collaborative use
Initial population by HLN team
Access to NH Core Team
File repository
Scope
This project only, or ongoing use
4/20/2019

13. Project Phases Initial Information Gathering
Key Tasks
Initial Information Gathering
Develop Gap Analysis Methodology and Tools
Conduct Review/Gap Analysis
Develop Options and Recommendations
Infrastructure/Architecture
Systems
4/20/2019

14. Facts and Findings at-a-glance
83 total systems documented
16 future, 4 current enhancements, 1 retired
46 in PHIN 1.0 functional areas
27 systems in-house with low architecture compatibility
“Fairly typical proliferation of standalone systems”
22 systems identified as “opportunity areas”
15 are in PHIN 1.0 functional areas
5 are ASP systems
Hosting model: 18 ASP systems
4/20/2019

15. Inventory Database: Systems at-a-glance
4/20/2019

16. Hosting Configuration
4/20/2019

17. Architecture Compatibility
4/20/2019

18. Interoperability Potential
4/20/2019

19. Project Phases Initial Information Gathering
Key Tasks
Initial Information Gathering
Develop Gap Analysis Methodology and Tools
Conduct Review/Gap Analysis
Develop Options and Recommendations
Infrastructure/Architecture
Systems
Revisit Vision & Goals
Establish Functional Priorities
Evaluate Options
4/20/2019

20. Functional Priorities
4/20/2019

21. Opportunities Chart Model Systems, Lower Priority Keystone Systems
Low Priority,
Low Potential
Problem Areas
4/20/2019

22. Model Comparison
In the center are those three interoperability objectives we discussed earlier. They exist along a continuum that has certain attributes.
First are a set of data attributes which lay in under these three objectives. Scope of data refers to the level of detail in the data itself and gets less detailed and more summarized as you move from left to right – from individual/person-specific data to aggregated data about groups of people to benchmark data which is often external to the organization and used by managers for comparison and assessment. Timeliness of data refers to the currency/immediacy of data and gets less frequent as you move from left to right. Real-time data is available between systems immediately; periodic data is available at some less frequent interval relevant to the particular need (could be daily, weekly, monthly, whatever); Occasional data is available even less frequently.
Next we have a set of systems attributes which sit above the three objectives (no reason these are above versus below – just a visual thing). Application Interoperability Strategy refers to the dominant style of application use, and moves further from the user’s existing applications as you move to the left. A Portal Application is usually a new application that tries to bring together data from many systems. It can be quite useful, but there is often a tension between the desire to use the neat features of the portal versus the comfortable feature of existing applications. Query applications tend to be separate and different from what the typical user is used to in their existing applications. Data Interoperability Strategy refers to the dominant style of technical architecture to support each type of interoperability. SOA (Service-oriented Architecture) uses component-based software building blocks to enable systems to interoperate through a standard set of interfaces. A Warehouse model aggregates data together from multiple sources (remember the slide above on that) and a Hybrid model uses elements of different approaches to achieve interoperability.
4/20/2019

23. Architecture for Interoperability
Address needs across the interoperability spectrum
Integration engine as hub for standards-based messages
Single pathway for data in/out of the department
Service Oriented Architecture (SOA): long-term goal
Warehouse and portal for short-term needs
Core requirements (messaging, vocabulary, security)
Web-based collaboration tools and content management
Systems Inventory Database
4/20/2019

24. Building NH PHIN Roadmap:
Enhance systems to enable PHIN messaging for Lead, TB, and Varicella. Practical, achievable set of initial projects on the road towards the recommended architecture
PHIN Directory
Incremental improvements to HAN
Incremental progress towards overarching goals
Unified messaging
Enterprise-class systems
Continued investment in Data Warehouse, LIMS migration, AHEDD
Systems Inventory
4/20/2019

25. Action Steps Execute roadmap
Apply the core requirements to new acquisitions
Leverage existing assets where possible
Periodically re-assess
Remain flexible and prepared for new opportunities
Use the System Inventory Database to its full potential
Participate in Health Information Exchange and Health Data Standards efforts
4/20/2019

26. Questions?