9/10/2015 8:10 AM HL7 Service-Oriented Architecture SIG OMG Healthcare Domain Task Force Open Health...
-
Upload
alvin-merritt -
Category
Documents
-
view
219 -
download
3
Transcript of 9/10/2015 8:10 AM HL7 Service-Oriented Architecture SIG OMG Healthcare Domain Task Force Open Health...
04/19/23 13:32
HL7 Service-Oriented Architecture SIG
OMG Healthcare Domain Task Force
Open Health Tools
Healthcare Services Specification Project
The Business Case for Healthcare SOA Standards
January 2013January 2013
Page 2
AcknowledgementsContributions to this content have come
from:Health Level Seven (HL7)
http://www.hl7.org
Object Management Group (OMG) http://www.omg.org
With additional contributions from:Integrating the Healthcare Enterprise (IHE)
http://www.ihe.net
Open Health Toolshttp://www.openhealthtools.org
Page 3
page 3
What is the Healthcare Service Specification What is the Healthcare Service Specification Project? Project? A joint standards development activity occurring in multiple
organizations, including Health Level 7 (HL7), the Object Management Group (OMG), IHE, Open Health Tools, and others
An effort to create common “service interface specifications” tractable within Health IT
Its objectives are:To create useful, usable
healthcare standards that address business functions, semantics and technologies
To complement existing work and leverage existingstandards
To focus on practical needs and not perfection
To capitalize on industry talent through open community participation
PolicyBusiness
Drivers
InformationModels
Service Funct.Model
RFP
Profiles
TechnicalSpecifications
Implementations
Requirements
Government, Professional Societies,…
Healthcare Organizations
HL7, openEHR, CEN, …
HL7 Domain Committees, CEN, Standards Bodies (SDOs)
OMG Healthcare Domain Task Force
IHE, SDOs, Healthcare Orgs
IHE
OMG, RFP Submitters
Interop Testing
Vendors, OHT, Healthcare Orgs
Page 4
What type of products do you produce? SOA Functional Standards [Service
Functional Models]Define the scope, purpose, and information content of
industry standard healthcare services Technical Specifications for balloted
Functional StandardsBind functional specifications into specific technologies,
transport protocols; technical conformance criteria Implementation Guidance & White
PapersNon-normative guidance to help consumers apply and
use HSSP specifications within their organizations. Not standards.
Page 5
2012 Key Milestones
Jan: HL7 Meeting (San Antonio) Jul:
Feb: Aug:
Mar: OMG Meeting (Washington) Sep: HL7 Meeting (Baltimore) > Ballot: Medication Stmt Profile Ballot anticipated> Ballot: Common Terminology Svcs 2 Normative Edition
OMG Meeting (Jacksonville)> Anticipated adoption: Services Directory (ServD) > RFP for Clinical Info Model Profile for UML to be issued
April: Interconnected Health Conf (Chicago)> Conference Proceedings can be found here
Oct:
May: HL7 Meeting (Vancouver)> Finalize Retrieve, Locate, Update Service Normative Spec
Nov:
Jun: OMG Meeting (Boston/Cambridge) > Revised submission of Services Directory (ServD)> “Information Day” on Healthcare Services
HL7 Italy “Open Days” (Rome, IT) HL7 Singapore SOA “Town Hall”
Dec: OMG Meeting (SFO/Burlingame)> Ballot: Medication Stmt Profile Ballot anticipated
Page 6
Core Project Principles
Leverage each community to its strengthOrganizations jointly participate in all
activitiesWork products will be “owned” by only one
organization but used collaboratively“Operate as one project” as a principleActively seek vendor participationRecognize that participation is an
investment
Page 7
HL7
OMG
The HSSP Process
HL7 DSTU
Service Functional Model
RequirementsOMG RFP
Technical SpecificationLessons Learned
ANSI Standard
Page 8
SFM
Understanding HSSP Artifacts, Roles, Attributes
Owned / Produced by
HL7 Community
RFP Submission Implementation
Defines what a service does but not how
Independent of technical platform
Audience is tech leads, EAs,
tech spec developers
Produced / owned by OMG
community
Translates SFM into technical requirements
ID’s supported technical
platforms
Audience is community with implementation
interest
Produced by OMG Member “Submitters”
Defines the service’s
technical spec
Defines interfaces, platform bindings, and conformance
profiles
Audience is project team
architect, lead developers, etc.
Owned by organizations and vendors
Builds the service that lives behind
the interface
Conforms with a “service profile”
Audience are consumers of the
system or service
Page 9
page 9
Asset InventoryAsset InventoryAsset Purpose Functional
SpecificationTechnical
SpecificationImplementation
Availability
Entity Cross-Reference Service (IXS)
To manage and correlate identities and identifying traits (e.g., MPI)
Complete Complete Commercially Available
Retrieve Locate Update Service (RLUS)
To manage location and retrieval of healthcare content
Complete Complete In Development
Decision Support Service (DSS)
To analyze patient data / assess knowledge rules.
Complete Complete Open Source
Common Terminology Service (CTS II)
Defines behavior for managing/maintaining terminologies
Complete Complete Open Source
PASS [Healthcare] Access Control Service
Manages security policy as pertaining to access to health information
Trial Use Standard
Complete(Beta)
Commercially Available
PASS [Healthcare] Audit Service
Security-oriented service to manage audit record
Trial Use Standard
Complete(Beta)
Commercially Available
Healthcare and Community Services Provider Directory (HCSPD)
To find providers & services in allocated areas, e.g., referrals.
Complete September 2012 Under Development
hDATA Record Format Specification
A hierarchical format with metadata tagging for organizing / representing [clinical] data
Complete N/A Open Source & Commercial
hDATA RESTful Transport Specification
REST binding for data retrieval using SOA (RLUS for REST)
Complete Expected 9/2011
Open Source
Page 10
Which services are being done next?We do not prioritize new work based
on a roadmap. Even if we pick priorities, that doesn’t
assure that people will do the workThis approach is not business-drivenThe committee is unfunded
New should conceptually align with the roadmap
We strive for consistency in service granularity
Work that does not conceptually align will be considered and perhaps undertaken or adapted.
Page 11
We will start new work when…There is a single person personally
committed to lead itWhy? Without a leader with day-job support,
the cycles simply aren’t sufficient to get the work done.
A core group of at least 3 organizations will participate.Why? Without a core group of three there is
not enough diversity to justify an international standard
There is a clear scope-of-work achievable in 12-18 monthsWhy? If work cannot be done in this
timeframe, the scope is probably either unclear or too ambitious
There is an agreement to work within the rulesWhy? This doesn’t mean that everything we
do is right. It does mean that if something doesn’t work, we need to fix it together.
We take on new work “top down” aligned with the roadmap with “bottom-up” prioritization
Page 12
Context of HSSP Specifications
Page 13
page 13
Interoperability RealizedInteroperability Realized
Context ConstraintsRequirements
En
terp
ris e
Info
rmati
o nC
om
pu
tati
on
a lEn
gin
eeri
ng
Page 14
How are HSSP services expressed?
Semantic Space/Universe
Formalism (Structure)
Semantic Signifiers(profile-relevant
semantic structures)
Usage Context(interoperability
paradigm)
FunctionalSubset List
(enumerate Supported Functions)
Ve
rsio
nS
ub
mitt
er
Na
me
Metadata Metadata
Page 15
The Benefits of HSSP Standards…
Define industry standard behaviors for healthcare-oriented service functions
Eliminate “different flavors” of web services from occurring in different organizations
Rapid-pace stds development: ~18-24 months
Methodology embracing cross-group standards development
Page 16
Where would these specifications be used
Inter-Enterprise (such as NHIN, RHIOs, HIE’s) By functionally specifying behavior, roles between
applications and products are clarified, and the technologies supporting them can be profiled and sharpened
Intra-EnterpriseStandardization on functionality allows for better integration
of off-the-shelf and custom development environments, and promotes more of a “plug and play” environment
Intra-ProductFacilitates vendors ability to integrate third-party value-add
components and speed design phase with higher confidence Custom-Implementation
Affords organizations wishing to custom-develop the opportunity to later integrate off-the-shelf
Page 17
HL7 ’s Services-Aware Interoperabilty Framework identifies architectural perspectives and levels describing and affecting interoperability
Conceptually HSSP activities are aligned with SAIF.
Includes SOA-based behavioral framework and conformance framework for HL7 standards (including HL7 v2 and v3 messages, CDA documents and services)
Utilizes SOA and Model-Driven Architecture principles for explicit expression of policy, governance and traceability
HSSP and the HL7 SAIF
Page 18
The Value of HSSP …
Value Rationale
Promotes deployment ease and flexibility
Specifications will support multiple topologies and technologies
Consistency at the interface level assures asset protection
Standard interfaces means that conformant components are substitutable
Multiple vendor product use/ interoperability
Using compliant products means side-by-side interoperation of multiple product offerings
Increased buyer/product offerings Consumer demand will create increased marketplace competition
Facilitates integration Unity in purpose and consistency in interface eases integration burden
Time to market Availability of an industry-accepted component interface eases product development burden
Requirements definition – influence vendors in a direct way
Participation by provider and payer community is direct expression of business need
Lower cost = wider deployment = higher quality service
Page 19
Why participate in standards at all? This is happening, with or without
you. We’d rather it be with you…
Unparalleled Networking. Standards work
provides access to the industry’s best and brightest Benefit from “lessons learned” from
others. Someone else may have already solved your biggest problem.
Industry Leadership. Standards work provides
a platform for you to establish market presence. Risk avoidance. Increasingly, standards
compliance is mandatory. Make them work for you and not against you.
Page 20
Why should I participate in HSSP?
This effort is focused on and driven by business-needIt is not an “academic exercise” striving for
perfectionStandards must be used to be useful Focused on the practical and achievableShort timelines Based upon business value and ROI
Leveraging talent from multiple communitiesBeing run like a “project” and not a
committee
We recognize that participation is an investment and not an expense
Page 21
How do I Participate? Participation is open to everyone. You don’t need to
be a member (though we encourage you to do so) Join appropriate standards organizations
HL7 for functional workOMG for technical specification work
Allocate resources to actively engage in the projectEngage existing, knowledgeable resources in the
areas they are working already.Subgroups form based on industry need and priorityTeleconferences are weekly; meetings
approximately bimonthly
Page 22
How is this project “different”? Active participation from three continents and 15+
organizationsSignificant cross-cutting community involvement
Providers & Payers (Blue Cross/Blue Shield, DoD Military Health System, Duke University, Kaiser-Permanente, Mayo Clinic, Veterans Health Administration)
Vendors, Integrators, Value-added Providers (Booz-Allen Hamilton, CSW Group, EDS, IBM, Initiate Systems, Intel, Northrop-Grumman, Ocean Informatics, Software Partners, 88Solutions)
Governments (Canada Health Infoway, DoD Military Health System (MHS), National Cancer Institute, NeHTA (Australia), SerAPI (Finland), Veterans Health Administration, Victoria Health (Australia))
Managing differences between SDOs in terms of membership, intellectual property, and cost models
Page 23
Who should I involve?
Involve the staff that can best address your business needs:You will get out what you put in. Senior
staff will drive more value and ROI to you than a junior associate.
Organizations that commit resources garner more influence and more mindshare
Your business interests are being represented by your attendees
Page 24
ReferencesAll HSSP artifacts and work in process are
open. Visit us at: http://hssp.healthinterop.org
Page 25
Supplemental Slides: Supplemental Slides: HSSP Stakeholder Benefits and HSSP Stakeholder Benefits and ImpactsImpacts
Supplemental Slides: Supplemental Slides: HSSP Stakeholder Benefits and HSSP Stakeholder Benefits and ImpactsImpacts
Page 26
SOA ≠ Web Services
SOA Web Services
Is a technology platform? No Yes
Is a transport protocol? No Yes
Primary ownership is business-line owned?
Yes No
Affects workflow and business processes? Yes No
Is an enabler for business and IT transformation?
Yes Yes
Is an industry standard? No Yes
Page 27
Why “services”?*A common practice in healthcare, just not yet in
healthcare ITMany key products use them but do not expose interfaces Ensures functional consistency across applicationsAccepted industry best practice Furthers authoritative sources of dataMinimizes duplication across applications, provides reuseMessages can be either payloads in or infrastructure
beneath servicesService-oriented architecture provides the framework for
automation of common services
*slide adapted from a Veterans Health Administration Presentation, used with permission
Page 28
What Participants are Saying… “Kaiser Permanente I.T. is currently transitioning to an SOA-based
approach to business and systems integration. Availability of industry standard services will bring many benefits towards this goal in terms of speed of implementation, flexibility and reduced cost. I am very pleased that both HL7 and OMG are committed to this timely effort.”, Alan Honey, Enterprise Architect (Principal), Kaiser-Permanente
“The creation of a health Informatics infrastructure based upon a service-based architecture grounded in comparable data has the potential to improve healthcare delivery and greatly enhance patient safety.”, Peter L. Elkin, MD, FACP, Professor of Medicine, Mayo Clinic College of Medicine
“The Eclipse Foundation is pleased to support an open source project dedicated to building frameworks, components, and exemplary tools to make it easy and cost-effective to build and deploy healthcare software solutions. This Eclipse Open Healthcare Framework project will leverage the Eclipse Platform developed by IBM, Intel, Wind River, Actuate, Borland, BEA, Computer Associates and others.” Mike Milinkovich, Executive Director, Eclipse Foundation
“The time is now and the place is here in this joint OMG/HL7 project. Never before has the industry been closer to cogent, clear healthcare IT data model and service standards that can provide true interoperability in a short timeframe, with open-source implementations making availability abundant.”, Richard Mark Soley, Ph.D., Chairman and CEO, OMG