New Developments in HL7 HL7

1
New Developments in HL7HL7????

• Brad Lund, Manager HIT Standards and Enterprise
  Architect Co-Chair HL7 SOA SIG/TC
• SOA Material initially prepared by John Koisch,
  OCTL Consulting
• PHR/IMC Material prepared by John Ritter,
  Enterprise Architect, Intel Corporation

2
Goals??

• The goal of this session is to present
• Overviews of New Developments in HL7,
  specifically targeting four programs and their
  importance
• SOA4HL7 (SOA SIG) / OMG HSSP Discuss SOA and
  standard based service interfaces and the
  evolution towards SOA within HL7 and the OMG/HSSP
  Relationship with example of one service Entity
  Identification Service
• PHR Functional Model
• Continuity of Care Document (CCD)
• International Mentoring Committee

Service Orientated Architecture Object
Management Group Healthcare Services
Specification Project
3
Web Services v Services v SOA

• Web Services is a technology
• Classic web services stack XML, SOAP, WSDL, UDDI
• Usually HTTP based, but may use MQ (JMS, AMQP) or
  SMTP
• Can support SOA, but also can support messaging
  or document paradigms
• Services
• Well defined Functional Components, cohesive
  collections of business or infrastructure
  functionality, exposed through well-defined
  interfaces
• Separation of interface from implementation,
  service clients depend on the interface contract
  only, not internals of the implementation.
• Service Oriented Architecture
• Overall cohesive framework and approach for
  defining and using Services, focus on business
  perspective.
• Architecture focus e.g. loose coupling,
  separation of concerns
• Focus on model driven solution delivery
• Common, standards-based infrastructure for
  distributed computing, providing the ilities
  (availability, reliability, scalability,
  performance)
• Complements Business Process automation,
  separation of Process from Service

4
Why Services and SOA

• Accepted IT industry best practice, Because
  everyone is doing it. A common practice in IT,
  and now increasingly common in healthcare IT
• Closer to plug and play.
• Business Agility (biggest advantage) able to
  rapidly change one component / system while
  minimizing impact on other components / systems
• Better alignment between IT and the business
  (more and more businesses tend to think in terms
  of services they offer or consume)
• Faster and simpler to develop and use
• Substitutable implementations (assuming shared
  information semantic understanding)
• Minimizes duplication across applications,
  promotes (does not guarantee) reuse.
• Still has to be done well, it is cheaper and
  easier than ever to create badly designed
  applications and spaghetti integration

5
Why is Health I.T. so Different ?

• Health I.T. is way, way behind the IT SOA
  adoption curve
• In some cases, for good reasons risk
  averseness, privacy and other regulations,
  complex information structures
• Others less so unwillingness to change, very
  slow processes for standardization
• Tooling (IDEs, wizards, specifications,
  supporting standards) lags in supporting Health
  IT developers
• Cutting edge clinical systems arent built to be
  integrated easily
• Looking at HL7 standards
• HL7 v3 messaging treats Web Services as a pure
  transport mechanism
• HL7 v3 messaging is intended to replace v2, but
  adoption is slow, implementation is very complex
• But has embraced model driven approach

6
Evolution of SOA/Services in HL7

• Web Services as Transport (Phase 1)
• HL7 WS Profile
• Web Services as Enabling Technology (Phase 2)
• Creation of SOA 4 HL7 (SOA SIG)
• Dynamic Model derives from
• State changes to the focal class Trigger events
  Interactions Application Roles define systems
• WSDL ties complex message types to operations
• Standard Services (Phase 3)
• OMG HSSP Service Specifications
• Services Interoperability Paradigm
• SOA (Phase 4)
• Compliant with Reference Architecture
• Meta-model Implementation Guides Profile
  Registry Template / Static Model Registry
  Governance Service Taxonomy

? We are currently here
7
A common conception of Healthcare SOA

• This is a decent view of business communications
• This is good context
• This is a nice org chart

BUT!
This is not a good SOA
What else is needed?
From http//hssp-infrastructure.wikispaces.com/spa
ce/showimage/CORBAmed_2000_05_01_ROADMAP_2_0.doc
8
Defining Services based on HL7 Messaging
Artifacts Problem Statement

• There are not yet many standard service
  interfaces defined
• Including agreed information and behavior
  semantics
• Defining new ones takes time
• Common taxonomy or layering of types of services
  (e.g. process, core business, data access)
• What to do with more urgent development or
  implementation needs?
• For software vendors define services using
  custom methodology based on own database schema
  (most common current practice)?
• For consumers or in-house developers create
  service definitions from scratch or from own
  legacy systems ?
• Or apply some level of consistent methodology?
• What about existing v2 or v3 messaging artifacts?

Enter SOA4HL7 (HL7 SOA SIG)/OMG HSSP
9
SOA4HL7 (SOA SIG) Work Products and Deliverables

• Methodology (Balloted HL7 informative document)
• Methodology for creating service definitions and
  implementations. This offers a more consistent
  way to define and implement interim Services
  based on HL7 V3 content. NOT a replacement for
  standard HSSP Services
• SOA Architecture Framework
• Leverage existing IT standards to enable services
  to be consistently described and used in
  healthcare environments. Includes a mapping of V3
  Infrastructure a the SOA framework. Again an
  interim until HSSP Reference Architecture is
  complete. Note - This artifact was not balloted.
• Focus here is on methodology

10
SOA 4 HL7 - Overall Methodology

• 1. Functional Specification
• Define Requirements
• Define Process and Information Capabilities
• Id and Name Service Components
• Map Requirements to Components
• Produce Logical Specification
• 2. Solution Specification (PIM)
• Refine Interaction Solution
• Refine Component definitions
• Define Detailed Dynamic Model
• Specify Operations and Messages
• Define QoS considerations
• Produce PIM Specification

• 3. Technical Specification (PSM)
• Platform Selection (e.g. WSDL)
• Identify Services (/consumers, interfaces,
  operations, parameters)
• Produce Interface Specification
• Define Technical Conformance Levels

This is only part of the solution, how do we
turn interface specs into implementable solution
specs
11
Healthcare Services Specification Project (HSSP)

• The Healthcare Services Specification Project
  (HSSP) is a joint venture between Health Level 7
  (HL7) and The Object Management Group (OMG).
• HSSP relies on HL7s national and international
  domain expertise and world-class information
  models to provide Functional requirements and
  specifications
• OMG brings the technology industry to the table
  by issuing a Request for Proposal (RFP).
  Submitting organizations create the Technical
  Specification
• HSSP is young it has been around for around 2
  years or so, and is growing

12
HSSP Timeline
2006
2007
2008
2009
Service
EIS RLUS DSS CRFQ CTS II HPDS PASS
HL7 SFM DSTU Ballot
OMG RFP Issued
OMG RFP 1ST Submission
HL7 SFM DSTU Approved
OMG RFP Final Submission
HL7 SFM Full Standard Ballot
OMG RFP Adoption
HL7 SFM Full Standard Adoption
13
So why standard Healthcare Service
Specifications?

• Provide common architectural building blocks
• Solve problems and create opportunities for
  developers / architects to improve healthcare
  with technology
• For consumers it provides cheaper and faster
  integration
• Enable inter-organization interaction over the
  internet using a common approach
• Tie good SOA practices and patterns to the rich
  models of HL7, CEN, OpenEHR
• Create true Interoperability specifications, not
  just Integration specifications
• Support and enhance the usage of existing
  Information Models

14
The Core HSSP Process(Service Specification)
HL7
HL7 SOA SIG
Service Functional Model
OMG
OMG HDTF
HL7 DSTU
OMG RFP
ANSI Standard
RFP Responders
Technical Specification
15
Example - EIS Specification

• Key requirement for cross organization and
  international relevance - functional consistency
  across service deployments with the ability to
  bind to different Information constructs
• Simple Example Create a service that provides
  identity resolution within one identity usage
  domains.
• More Complex Examples
• Supporting multiple content models within common
  interfaces
• Federating across multiple domains, both
  hierarchic and peer-to-peer topologies
• Relate various different roles of a person
  together

16
Context

• The Entity Identification Service (EIS) SFM
  provides a set of functional behaviors which
  enable unique identification of entities (such as
  patients) within disparate systems, both within
  a single enterprise and also across a set of
  collaborating enterprises.
• Classes of entities could include a variety of
  entities, e.g., providers, equipment, payers,
  even animal subjects in clinical studies.
• Conceptually, the EIS is a superclass of Master
  Person Index
• Updates and extends the OMG Person Identification
  Service (PIDS) spec and the IHE PIX/PDQ profiles

17
Core Service Operations
Functional Interface
Function Call
Create a Patient Identity
EIS
Service Client
Create Entity(Person, ID, Bob)
Acknowledgement
Look up a Patient
Find Entity with Traits (Person, Bob)
Person ID List including Bob
Link Patients
Link Entities (Person, newerBob, Person, olderBob)
Acknowledgement
18
Scope of Specification Work

• EIS functional specification (HL7)
• Business Cases and requirements
• Interface Definitions
• Initial Conformance Profiles (Interfaces
  Semantics)
• EIS technical specification (OMG)
• Administrative interfaces
• Technical requirements (performance, scalability,
  extensibility)
• Further Conformance Profiles (e.g. HL7 V2 format,
  HL7 RIM Patient)
• Platform Bindings (e.g. SOAP / WSDL)

19
Personal Health Record Functional ModelPHR-FM
20
Overview of the PHR-S FM Standard

• What is a PHR?
• One possibility Define an PHR as a small list of
  Personal Health-related data with no connection
  to an EHR-S and no professional input
  capabilities.
• Another possibility Define a PHR to include
  behavioral health, community health, public
  health, healthcare-related workflow, and
  patient-entered / patient-accessed data,
  medicines, care plans, etc., with connections to
  labs, pharmacies, financials, nursing homes, with
  professional input capabilities.

21
Overview of the PHR-S FM Standard

• By consensus agreement, a PHR system should
• Be consumer-oriented
• Provide a Longitudinal collection of personal
  health information
• List the functions that PHR systems shall,
  should, or may do
• Provide immediate electronic access to the
  consumer and to those authorized by the consumer
• Serve as an anchor point for system
  interoperability
• Provide a certification framework

22
Business case for the PHR-S FM

• There are currently about 1000 different PHR
  implementations and the number is growing. Are
  they interoperable? No. (Thus the need for a
  standard.)
• Customers reluctant to purchase non-certified or
  non-standards based systems
• Large employers desiring to have healthier
  employees want to empower them with knowledge to
  make informed decisions, but need a way to
  implement that desire

23
Overview of the PHR-S FM Standard

• The resulting PHR-S FM standard is
• Consensus-based
• Internationally-oriented

24
Overview of the PHR-S FM Standard

• Five Chapters
• Overview
• Conformance Clause
• Personal Health
• Supportive
• Information Infrastructure

25
Sample Function in the PHR-S FM

• PH.2.5.1 Manage Problem Lists
• Statement Manage the account holders health
  problem list and provide the ability to manage
  the problem list over time.
• Description Problems are a core feature of the
  medical record that provides structure and direct
  management. Problems may include diagnoses
• Example Problem list items may include chronic
  conditions, diagnoses, allergies, or symptoms,
  both past and present, as well as
• 1. The system SHALL provide the ability to
  capture, display and report all problems
  associated with an account holder.
• 2. The system SHALL capture, display and report a
  history of all problems associated with the
  account holder.
• 3. The system SHALL provide the ability to
  capture the date the problem was documented.
• 4. The system SHOULD provide the ability to
  capture the chronicity (chronic,
  acute/self-limiting, etc.) of a problem.
• (...)
• 11. The system MAY provide the ability to
  consolidate or group multiple problems or related
  problems under a single problem.

26
Business impact

• Vendor qualification and selection
• Which partners? What is their value?
• System scoping
• What will we build? What wont we build? How will
  we define the parts?
• Interface requirements definition
• A well-scoped, well-defined module gives rise to
  clearer, cheaper, better interface definitions
  loosely coupled architectures (e.g., SOA)
• Marketing
• Our product is standards-based and has a Seal
  of Approval -- sign here.
• Apples-to-apples comparisons become possible

27
Business impact (cont)

• Scalability
• Standards-based widgets scale better
• Interoperability
• Technical, Semantic, and Process
  Interoperability are more achievable when systems
  and system endpoints are standards-based
• Internationalization of products
• Standard Terminologies and code sets, etc.

28
Proposed Next Steps

• Receive training on the PHR-S FM, profiles,
  certification
• Cast proposed solutions in well-defined (i.e.,
  PHR-S FM) terms
• Use (or create) profiles for your solution set.

29
CCD and IMC
30
Continuity of Care Document (CCD)

• Collaboration between HL7 SD/CDA TC and ASTM E31
  Health Informatics Committee
• CDA V2 CCR CCD
• Approved by Healthcare Information Technology
  Standards Panel (HITSP)
• recognizes the successful harmonization of two
  sets of standards
• A true interoperability standard that enables
  clinical data to be transportable, resulting in
  improved quality, enhanced patient safety and
  increased efficiency
• Can be used to send electronic medical
  information among providers without loss of
  meaning.
• Clinical information that can be exchanged
  includes patient demographic data, medications
  and allergy information.

31
International Mentoring Committee

• Assists potential Affiliate organizations with
  appropriate guidance and education to permit them
  to improve their processes and procedures
  sufficiently to become viable Affiliate
  organizations.
• Technical assistance visits and peer-to-peer
  exchanges to Affiliate or potential Affiliate
  countries.
• Mentoring generally takes place via
  teleconferences, e-mail and meetings in
  conjunction with scheduled HL7 Working Group
  Meetings and may include bringing delegates to
  scheduled HL7 events
• Develop and maintain a list of individuals,
  firms, professional organizations, and other
  agencies who have agreed to assist any potential
  or struggling Affiliates or who may be contacted
  for educating key decision makers and persons of
  influence as to the value of HL7 and Affiliate
  organizations.

32
How to qualify candidates?

• Detailed Questionnaire for candidates (includes)
• Your role?
• How much governmental support for standards?
  Political?? Monetary??
• Current healthcare infrastructure?
• Most pressing issues?
• Top roadblocks?
• Which HL7 topics are you interested in?
• Questions for HL7?
• How can HL7 help you?
• How can you help HL7?
• How to measure success (value) of the WGM
  visit?

33
Contact Information

• SOA SIG
• soa_at_lists.hl7.org
• PHR-FM
• www.HL7.org/ehr
• CCD
• ccd_at_lists.hl7.org
• strucdoc_at_lists.hl7.org
• IMC
• InternationalMentors_at_lists.HL7.org

34
Thank you Questions