Transcript Otsikko - uef.fi

Healthcare software
services
- open interfaces and
standards in Finland
f
HL7/OMG Healthcare Services Specification Project
London, 31 Jan 2006
Juha Mykkänen, University of Kuopio, HIS R&D unit
SerAPI project, HL7 Finland CS SIG
Overview
 healthcare & health information systems in Finland
 open service-oriented interfaces: efforts and
specifications in Finland
 HL7 Finland Common Services SIG
 PlugIT project
 SerAPI project
f
 comparison of three services
 experiences
 national efforts
 HSSP
Healthcare & HIS in Finland
Kuopio
Helsinki


Healthcare in Finland
 Population 5.3 million
 Life expectancy 74.6 / 81.5 years
 GDP per capita 28,646 EUR (2004)
 Growth competitiveness index score (World Economic Forum
2005) 5,94 (1st)
 Healthcare 7.6% of GDP
 Public healthcare funded by taxation
 Basis: 278 primary health centres
f by 444 municipalities
 5 university + 32 central/district hospitals in 20 districts =
associations of municipalities
 Private care 14%
 Occupational health by private organisations
Information systems in healthcare in Finland
 In primary health care, EPR used by 98% of GPs
 In hospitals, HIS used since 1980s
 Now: EPR to hospitals, integration, migration, web-based systems
– National interoperable EHR by 2007?
Background: HL7 Finland Common
Services SIG
 HL7 Finland
 held its 10th anniversary in October 2005
 HL7 v2.3 messaging widely used in some domains
 active in national work for EHR
 CDA r2 used as a basis for the structure and archiving
 HL7 Finland Common Services SIG (2002-)
f
 initial focus on clinical context
integration (CCOW)
 work on service specifications from the background
projects - national comments, balloting
 3 available specification areas + implementation guides
Background: PlugIT project
www.plugit.fi
Government
Guidance,
resources
Educational and
research institutions
Software
companies
Teaching
Intl.
links
Basic
research
Applied
research




Healthcare / welfare
service providers
R&D
Actors,
methods
Needs
3 univ. depts,
1 polytechnic
Natl. healthcare programme /
National EHR project
Softw.
devel.
IT
support
f
Sales &
support
Products,
consultation
Needs
12 applications
vendors, 3 technology
vendors
IS
project
ISenabled
care
Communities,
citizens
Health/welfare
services
Better
life
Needs
6 hospital districts,
2 municipalities
National R&D project to develop integration solutions for healthcare
Results: Service specifications, integration methods, centre of expertise
Oct 2001–Aug 2004, about 15 full-time + 15 part-time researcher/developers
Budget € 2 million, 84% by National Technology Agency TEKES
Background: SerAPI
 SerAPI project (2004-2007)
 national R&D project
 service-oriented architecture and web services
 14 software companies, 4 public healtcare organisations,
3 research units
 process / application / platform viewpoints
 service specifications, methods
and tools
f
 participation in standards development (national /
international)
 Healthcare Services Specification Project
 participation through both OMG and HL7
 infrastructure work / individual services
Open service specifications
 HL7 Finland accepted
 Context Management (context repository) ~ CCOW
 Core services: User & Person information access +
Access control ~ EIS, OMG PIDS
 Core services: CodeAPI ~ Common Terminology
Services Vocabulary API, OMG TQS
 other publicly available
f
 DRG classification
 OID generation
 other in progress and related
 scheduling ~ e-booking
 decision support
 patient lists, care relationship, etc.
Service implementations
 several context service applications
 context services available in core applications in hospitals
and health centres
 low effort implementation for single sign-on + patient
synchronisation
 recent additions for security in regional information
systems
 core service implementations fin university hospitals
 implementations in new core hospital systems
 also legacy applications wrapped with interfaces migration
 several proprietary services, some specifications available in
public
 DRG classification, care relationship, decision support
service pilot etc.
Approach + interface technologies
 incremental specification: from functional interface
specification to technology-specific interfaces
 simple http communication (context management)
 http + XML (user, person, etc. HL7 specifications)
 WSDL/SOAP with WS-I, "API style" (versions of user,
person etc. core services, fDRG, OID)
 in addition to
 CDA documents (national EHR core technology) national "services"
 HL7 messaging (v2.3  v3 + Web services transport)
 others (EDI, custom solutions..)
Different types of services: three cases
 DRG (Diagnosis Related Groups) classifier interface
 resource utilisation groups (NordDRG) to support e.g.
invoicing and benchmarking
 EPR (Electronic Patient Record) archive interfaces
 variety of clinical documents stored in archives on
organisational, regionalf and national level - note:
national solution not yet specified
 Context repository
 single sign-on, synchronisation of several applications
(used by one user) to one patient at a time etc.
Comparison of service scenarios 1
Scenario
DRG classifier
interfaces
Requirement Produce information
based on diagnosis
and other
information for the
assessment and
comparison of
resource
consumption
Integration
service
model
Adaptability static, parameters
well-known
Unified or
federated
unified model
(common service)
EPR archive
interfaces
Provide a common
interface for archiving
and retrieving
different types of
clinical documents
related to a patient
(e.g. referrals,
prescriptions)
information
f
Context repository
interfaces
Maintain user-specific
context information for
several applications
(user, patient,
encounter etc.)
dynamic, different
types of documents,
support for local
variation
unified model
(common archive)
and federated model
(content translations,
cascading archives)
static interface,
extensible subject
definitions
user
unified model
(common service)
Comparison of service scenarios 2
Scenario
DRG classifier
interfaces
fine-grained
operations and
parameters
EPR archive
interfaces
large-grained
documents
Context repository
interfaces
fine-grained operations
and parameters
Tight/loose
tight, common
service must be
available
loose, archive may be
queued, national
messaging service
tight, but applications
work also without the
service
Consumers
/ providers
many consumers use
one provider (one
organization)
many consumers use
one logical provider
f
(national,
regional)
many consumers use
one provider
(organization / region)
Message
exchange
pattern
immediate response
needed, find and
invoke
guaranteed delivery
needed, send and
retrieve
immediate response,
find and invoke
State
Additional
considerations
stateless
can be used in
interactive and/or
batch-oriented way
stateless
clinical documents,
functionally simple,
informationally
complex interface,
digital signatures
stateful
low implementation
threshold for
participating
applications, no bidirectional invocation
Granularity
Emphasis in Finnish efforts
 increased plug and play, reduced local tailoring
 simplicity and genericity: start from minimal but sufficient
 implementability
 low introduction threshold
 compatibility with existing systems
 defined path from requirements to implementations
 services as one part of thef big picture
 CDA (moving from regional to national level)
 messaging (v2  v3 transition is beginning)
 emerging architectures on local, regional and national
levels
 three-partite collaboration (vendors, hospital districts,
research)
Lessons & observations
 important: pragmatic approach and right timing
 acknowledge different types of services
 clear usability improvement, low introduction threshold and
little invasiveness have fostered the most uptake
 start where there is most repeated point-to-point integration
 nail down both functionality and information (does not mean
sacrificing flexibility)
f
 a unifying architecture would help
 differences in organisations, in regions and nationally
 "where to put the mandate.."
 HSSP: practical, community-driven, multi-platform...
 SOA main benefits: flexibility and interconnectivity
 moving from closed consortia to open standards community
 but quite bad conference call times for Europeans (EET) .. :)
Thank you
www.centek.fi/serapi/english.html
www.plugit.fi/

SerAPI project participants: National
Technology Agency TEKES (grants no
40437/04, 40353/05), Medici Data Oy,
Datawell Oy, Fujitsu Services Oy,
Hospital district of Northern Savo,
WM-data Oy, Commit; Oy,
f
Intersystems B.V. Finland, Mediconsult
Oy, Microsoft Oy, Oracle Finland Oy,
Hospital District of Satakunta, Bea
Systems Oy, Hospital District of
Helsinki and Uusimaa, City of Kuopio,
Kustannus Oy Duodecim, Mawell Oy
[email protected]