Transcript PlugIT-yleisesittely

PlugIT’s closing seminar, Kuopio, 30 Aug 2004
Updated 2 Nov 2004
PlugIT in a nutshell
PlugIT:n tulokset
pähkinänkuoressa
PlugIT: Healthcare Applications Integration, 2001-2004
www.plugit.fi
Mikko Korpela, Research Director, D.Tech., Docent
University of Kuopio, IT Services, HIS R&D Unit
(Healthcare Information Systems Research and Development Unit)
Centre for IT Education and Research Centek
[email protected]
All PlugIT personnel have contributed to this presentation
National Technology Agency Tekes grants 40664/01, 40246/02, 90/03
Contents of the presentation
•
•
•
•
•
•
•
•
•
•
•
Why the PlugIT project was needed?
Objectives and scope of the project
Implementors, partners, measures
Approach
Phases of the project
Results 1: Interface specifications
Results 2: Methods
Results 3: Know-how and expertise
Utilization of the results
Experiences
How should we be assessed?
Why the PlugIT project was needed – 1
Initial situation, spring 2001
• Pasi Markkanen’s survey for Tekes: Integration on top of the
healthcare software industry’s priority list of problems.
• In Kuopio University Hospital alone 180 information systems →
new systems integrated to existing ones by tailoring, expensive,
an obstacle to procurement by healthcare organizations.
• Increasingly in primary healthcare centres as well healthcare
professionals need more than one software application to
produce the care for a single patient.
• HL7 Finland and projects on regional information systems
developed means for interorganizational integration, but no
proper means available to the lack of interoperability
experienced by users (cf. project scope re. integration needs
within the healthcare delivery system).
Why the PlugIT project was needed – 2
Government initiatives (unofficial translations)
National Project to Secure the Future of Health Care,
recommendation no. 8, spring 2002:
• ”The interfaces between healthcare systems will be made
obliging to all healthcare actors by degree by the Ministry of
Social Affairs and Health by the year 2007.”
Minister of Health and Social Services, Ms. Liisa Hyssälä,
The Suomenmaa 9.3.2004:
• ”Badly interoperable systems are an obstacle to efficient
healthcare. Without integrating the information systems, the
accessability of care will not improve in the way the National
Health Care Project requires. The integration of expensive
information systems used in thousands of organizations is no
piece of cake.”
Objectives and scope of the project:
”Official definition”
PlugIT is a national, Tekes-funded
research and development project to produce
(1) open application program interface (API) specifications
as well as related (2) methods and (3) expertise
for healthcare software companies and their customers.
PlugIT will accordingly contribute to the implementation of the
recommendation no. 8 of the National Health Care Project.
The objective is to facilitate healthcare service activities through
the software development service chain, by means of more
interoperable clusters of software applications.
Integration needs in healthcare system
National health
administration
Province / district
health administration
Information
Management
Information
Management
Control,
coordination,
resources
Health Support
records services
Information
1.
2.
3.
4.
5.
Formal
organization
Control,
coordination,
resources
Activity
Need/service
relationship
Health centres
General hospital
Teaching hospital
Legend:
Local
government
Management
Clinics,
specialties
Health
records Care
provision
Care
provision
Health
records Care
provision
Citizens,
communities
Services
Services
Health services
Needs
Needs
Health needs
Data
Intra-activity: e.g. electronic record – scheduling;
PlugIT’s focus
Between activities within an organization:
care dept. – service dept.; HL7 messages
Between activities along a service chain: e.g.
referral – feedback, ”disease mgt systems”; HL7
Choice of services between organizations:
regional information systems, portals
eGovernment/Business: eHealth, citizen’s records
Social services
Private clinics etc.
NGOs, third sector
The problem in focus in PlugIT:
Cluster of software products
A physician or another health
care professional needs to
use several software
products to deal with a
single patient’s problem.
Each system has its own
access codes, patient data,
code sets, etc.
User X
Patient 1
Data A
User X
Patient 1
Data B
Work station
Application
A
Application
B
Data
Data
Users
Patients
Codes
Users
Patients
Codes
Server
Server
Healthcare software service chain:
How integration research will improve services
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
Softw.
devel.
IT
support
Sales &
support
Products,
consultation
Needs
IS
project
ISenabled
care
Communities,
citizens
Health/welfare
services
Better
life
Needs
Implementors, partners, measures – 1
Multidisciplinary and multiprofessional research group in Centek:
• Univ. of Kuopio, Health Policy and Management Dept., SHIFTEC
(Research Director Pekka Turunen → Anneli Ensio):
Healthcare professionals’ viewpoint
• Savonia Polytechnic, Savonia Business, Information Processing
(Principal Lecturer Maritta Korhonen):
Hospital Districts’ IT professionals’ viewpoint
• Univ. of Kuopio, IT Services, HIS R&D Unit
(Research Director Mikko Korpela, research leader in charge):
Method and tool developers’ viewpoint
• Univ. of Kuopio, Computer Science Dept., Software Engineering
(Professor Anne Eerola):
Software companies’ software professionals’ viewpoint
Implementors, partners, measures – 2
Representative group of competing software companies:
• 12 healthcare software companies: Commit; Oy,
General Electric Healthcare / Deio Oy, Enfo Oy,
Fujitsu Services Oyj, Mawell Oy, Medici Data Oy,
Mediconsult Oy, Mediweb Oy, Mylab Oy,
Suomen Posti / Atkos Oy, TietoEnator Oyj, WMdata Novo Oyj
• 3 software technology companies: BEA Systems Oy,
Microsoft Oy, Oracle Oy
Representative group of public healthcare providers:
• 6 hospital districts: Helsinki-Uusimaa, Pirkanmaa (Tampere),
Pohjois-Savo (Kuopio), PohjoisPohjanmaa (Oulu),
Satakunta (Pori), Varsinais-Suomi (Turku)
• Primary healthcare represented by City of Kuopio and SiilinjärviMaaninka
Implementors, partners, measures – 3
Basic measures:
• Biggest software engineering research project funded by Tekes
• Budget 2 million euros (~ US$ 2.4 million)
• 84% from Tekes, iWell technology programme
• → mid-term research, business impact expected in 3–5 years
• Each company/hospital district paid 2–9 000 €/year
• Three years, October 2001 to August 2004
• Employed simultaneously ~ 15 full and 15 part time
researchers/developers, supervisors and trainees
Neighbours and partners:
• HL7 Finland
• National Health Project’s subproject on
electronic patient record systems
• Projects on regional information systems
• Sonetti partnership by hospital districts in Eastern Finland
• Health Kuopio programme
Approach – 1:
International standards
HL7, OMG Healthcare Domain Task Force (ex
CORBAmed), CEN/HISA, ISO 215, IHE, HIPAA, …
Top down
Progressing from two directions
Terminologies, code sets, data structures
WHO, OID, STAKES, Association of Local
and Regional Authorities, National Healthcare Project, …
Families of infrastructure technologies
Corba family, Java family, Microsoft family, Web Services
Proprietary and two-party solutions
…, …, …
Bottom up
Healthcare process improvement initiatives
Macro Pilot Project, Sonetti, Pirke, National Healthcare
Project, …, …, …
Approach – 2:
Tripartite collaboration
Research teams search for information and develop methods.
Open interfaces are specified all together, driven by the teams.
Hospitals order interfaces from companies according to specs.
Pilot companies implement the interfaces and apply the
methods in their products with the support of the research teams,
other companies at their own cost.
Research teams document and publicize.
In practice:
• Semiannual seminars; presentations and workshops, ~70 pers.
• E-mail lists: Board, contact persons, project staff, supervisors
• Web pages: Public, contact persons’, internal, Board’s
• Several dozens of meetings with partner organizations
• Detailed report monthly, Board meetings twice a year
Phases of the project
1.
October 2001 – April 2002: Evidence for funding decision
– Recruitment, elaborating on the plans, gathering the
consortium, raising funding for the main phases
2.
May 2002 – October 2002: Foundations laying
– Meetings with partners, surveys, self-education
3.
November 2002 – April 2003: Full action, top down
– Selection of targets, establishment of teams, action plans
for specification teams, top down surveys, first
pilot/prototype case, company survey, methods
4.
May 2003 – October 2003: Bottom up, first specs
– Establisment of pilot/prototype cases, bottom up work with
companies, methodological development, first versions of
three interface specifications approved
5.
November 2003 – April 2004: Models, methods
– Reference implementations, push to pilots,
systematization of methods, new project proposals
6.
May 2004 – August 2004: Packaging
– Fine-tuning, documenting, publicizing the results
Results 1: Interface specifications
Two new means for interoperability
Desk top integration (Clinical Context Management):
• Context synchronization: Minimum level from HL7 CCOW
• Application launching and context exchange
Shared core software building blocks (Common Services):
• User and access rights interface
• Patient data interface (person data set, clinical data sets)
• Terminology interface (diagnoses, tests, organizations, …)
• More service interfaces in further projects
In practice:
• 6 teams, 14 integration objects, different needs
• 1+4 interface specification documents (from need to technology)
• 7 public reference implementations with documentation
• Testing procedure and test cases → ”PlugIT stamp”
• Training programme and teaching material for implementors
Results 1: Interface specifications
Solution 1: Context management
Example: Daisy Doctor has
opened an EHR system and
selected patient John Doe.
EHR system sends user and
patient IDs to context server.
When the physician clicks on
”regional data”, EHR system
launches a regional index
system. The latter retrieves
IDs from the context server,
starts up with Daisy’s access
codes and displays John’s
data from the regional index
data base.
User daisydoc
Patient John D.
Health record
data
User ddoctor
Patient Doe, J.
Regional data
Work station
Electronic
records
Regional
system
Context
Mgr
Data
Users
Patients
Codes
Server
Context
Data
User-ID X
Pat.-ID 1
Users
Patients
Codes
Server
Results 1: Interface specifications
Solution 2: Common services
Work station
Server
Server
Etc data
Codes
HIS core
system
Patients
Clinical
system
Rights
All applications’ common code
sets are updated from the
national terminology server.
Maintenance will decrease.
User X
Patient 1
Core data
Users
When e.g. a patient’s personal
data are modified via one
application, all other
applications will ”see” the
change immediatelly.
User X
Patient 1
Core and
other data
Clinical
data
Common data needed by all
applications are in a core
system. All applications can
use the common services
through standard ”plugs”.
Duplicate programming will
decrease.
Results 1: Interface specifications
APIs as a part of the national set of means
User X
Patient 1
Core and
other data
User X
Patient 1
Core data
User Y
HIS core
system
Dept.
system
Server
Server
Care organization
•
•
•
•
•
•
Code set
server
Code
sets
Etc data
Codes
Rights
Users
Clinical
data
Clinical
system
Patients
Work station
Server
Service organization
Stakes
Core data sets defined by the National Health Project
XML data structures defined by HL7 Open CDA
Terminologies and code sets from Stakes’s national server
Desk top integration and common service APIs from PlugIT
HL7 messages are used between organizations
Secure communication platform, consent practice, …
Results 2: Methods
Open integration specification process – the PlugIT process
Activity-driven methods for requirements analysis:
• Exploring a ”gray area”, home care as a case
• Feasibility study to prioritize needs, maternity clinic as a case
Application production and integration methods
(requirements, user interface, testing, tools selection, data
base, etc.): Prototyping with methods, Pakkanen as a case
In practice:
• 3 teams and a common ”team-team”
• 8 reports on methods and the case results
• Training programme and teaching material for adopters
• Basis for further projects
Results 2: Methods
Integration specification process
-health know-how
-pilot systems
-existing technologies
-functional and quality requirements
Work process
improvement
Application
vendors
-existing integration solutions
-pilot systems
-existing technologies and tools
-existing production and quality process
product
implementation
Acceptance
Deployment
Adaptation
Implementation
(pilot)
Integration
need
Project
plan
Piloting
plan
-list of initial integration needs
-specification guidelines
-content definitions for specifications
-example solutions
-templates
-tools
Description
of current status
local requirements
specification
work
iteration, new versions
-documentation
-evaluation
implementation -integration process
work
development
-generalization
-method
validation
4. IMPLEMENTATION
DESCRIPTION
Moderator
( PlugIT project)
Solution
specification
Context
studies, technology
evaluations
Open, reusable
integration specifications
Requirements
analysis
1.INTEGRATION
REQUIREMENTS
specification
2. PLATFORMwork
INDEPENDENT INTERFACE
SPECIFICATION
3. TECHNOLOGYSPECIFIC INTERFACE
SPECIFICATION
Mykkänen et al., MEDINFO 2004
Health service
provider (e.g.
hospital)
Results 2: Methods
From a ”gray area” to software requirements
As iakas
Oma
hoitaja
BASIC SERVICES
Ambu
lanssi
Käynti tiimituvalla
Herättelee ja
kys elee vointia
Team
Various
actors:
PLANNING
VISITS
Puhuu
sekavia
Kyselee vaivoja ja
mittaa kuumeen
Privacy Protection
Tarkistaa
illan
merkinnät
VIEST IVIHKO
FAX
Kysyy
neuvoja
Plan
Ksh
Soittaa ambulanssin
Home
helper
DOMESTIC
AID
keskus
Doctor
Customer?
Physiotherapist
Home Helper Nurse
Am bulanssi
saapuu
Relative/
Friend On-call
Cleaner
helper
Kertoo
tilanteen, antaa
Hopasun
Kirjaa
käynnin
Siirretään
ambulanssiin
HOPASU
Kuljettaa
asiakkaan
Plan
Service Providing
HOPASU
Kirjaa
tilanteen
VIEST I VIHKO
RN, MD:
HOME
HEALTH
CARE
Hätä -
päivystykseen
Ilmoittaa
omais ille
Omai
nen
Ilmoittaa
kpo:lle
Kirjaa
poiss aolon
Kpo
POISSA OLOT
Ateri
apalv.
Toivanen et al., AT in IT Design 2004
"Työkansio"
Results 3: Know-how and expertise
Concentration of expertise:
• Multidisciplinary group of about 20 people with expertise, the only
in Finland in applied research on healthcare software production
• In international comparison on a good European level
• Supported by the only concentration of education in information
technology and information management in healthcare and social
services in Finland: www.plugit.fi/ITesite.pdf (in Finnish)
In practice:
• 49 persons employed during the project, 2 worked without pay
• 16 MSc’s (4 in progress) and 5 BSc’s, 4 PhD’s in progress
• 34 international scientific papers and conference presentations –
MIE, MEDINFO, HL7, IFIP 8.2, STEP, IRIS, AT IT, …
• 36 domestic papers and conference presentations
• 16 reports and working papers in PlugIT’s own series
• ~60 presentations at lectures, training and other events
• 8 new project proposals (Tekes, Ministry, TSR, Academy), 5 appr.
Utilization of the results – 1:
Indirect national impact (unofficial translations)
National strategy on electronic patient records, Dec 2003:
• ”Desk top integration” will come from PlugIT
HL7 → MoH, Open CDA specification document, 2 Feb 2004:
• ”CDA specifications are intended for document transfer. Other
interactive support mechanisms are needed as well. PlugIT project
has developed specifications and a mechanism for patient selection,
based on Object Management Group’s PIDS service. It is proposed
that PlugIT’s PIDS specification will be made an official open
interface, so that the person data specification (profile) is based on
the person data form specified in the Open CDA project.”
Recommendation on national standards, Oskenet 7/2004:
• ”International interfaces should be used in application program
interfaces as the first choice […]. If they are not available, national
interface recommendations (like PlugIT interfaces) are to be
developed. National recommendations are needed on …”
Utilization of the results – 2:
National and international formal acceptance
HL7 Finland, spring-autumn 2004:
• Common Services SIG established
• Minimum-level context management nationally accepted on
13 October 2004
• User, access and person/patient interfaces to national approval
process in November 2004, terminology interface after that
HL7 International, winter 2003 - autumn 2004:
• Common Services appeared to HL7 agenda unofficially in 2003
• PlugIT’s results were presented in the HL7 conference in
Acapulco, October 2004
• International Services Specification will be started on Finland’s
proposal; U.S. Veterans Health Administration, Kaiser Permanente,
Canada, Greece, Australia joined
• Will the HL7 CCOW community accept a cheaper version?
Utilization of the results – 3:
Deploying the results into products and practice
Implementations in products by the end of the project:
• Two implementations of context server, one ”stamped” –
~10 products in the market which could potentially act as servers
(health centre systems, HIS core and comprehensive systems of
hospitals, regional systems, portals)
• One implementation of Common Services announced in 2004 –
~10 products in the market which could potentially act as servers
• Client applications making use of the services in plans –
several dozens of potential client products in the market
• Inquiries about using common service interfaces between
legacy core systems and new clinical systems or vice versa
Orders by hospital districts and health centres:
• ”Piloting orders” during the project
• Interest in using interface specifications in bids for tenders
Experiences – 1:
Are the results what we planned to do?
•
•
•
•
•
•
•
•
•
”Desk top integration” and Common Services: Central role in
the early plans, became unifying concepts and technically merged
Business components → Web Services
Multimedia components → generic application launching
The role of CDA-coded storage of records became stronger
Less work on design patterns and templates than planned
Reference implementations and prototyping vs. piloting
Activity/process development vs. software development:
Including ”soft” requirements methods into the project was right
Concentration of expertise was achieved, national
collaboration needed
Degree studies not sufficiently prioritized and supported
Experiences – 2:
Did we do it in the right way?
•
•
•
•
•
•
Subprojects by research units → multidisciplinary teams
Tripartite collaboration is a must! But practical interaction is
needed between professionals, not just management →
contact person who distributes and filters information to others
Government participation to be increased! The triade
service providers – companies – researchers is needed in
managing and implementing the National Health Project as well
University-Polytechnic collaboration was important but
hampered by bureaucratic obstacles (parallel funding)
More contacts to research on software product business:
Many problems and solutions are not domain-specific
International perspective is weak in Finland: Export is 20% of
healthcare software business, tendency towards two-party
homegrown solutions, international visibility is weak
Experiences – 3:
Making the most of research
To reap benefits from research, you need to actively seek for
benefits through active interaction!
• Some companies & hospitals were active, the majority tried to
keep abreast, a couple did not enter into an interactive relation
• Corporate timeframe vs. research timeframe:
”Give us a fish, not a fishing hook” vs. ”Philosophy of fishing” –
both are legitimate and need to be balanced.
• Pilots are the biggest problem – better as separate projects?
In the beginning of a 3-year project you don’t know what to
budget for practical integration projects during the last year.
Research projects should produce reference implementations.
• Industry funding for research may become a bottleneck:
Average-size non-pilot company paid for PlugIT’s €2 million and
3year results less than for the cheapest new car – which one
was a better investment? (Answer: Depends on the need)
How should we be assessed:
From PlugIT presentation at SoTeTiTe 2002
”What will have changed in August 2004 as a result of the
PlugIT project? How shall we be assessed?
• Do healthcare professionals have a more fluently
interoperable software cluster in use (in pilot sites)?
How can that be proved?
• Has software companies’ applications developers’ work
become easier (in pilot companies)? How to prove that?
• Are applications and software components more
transportable and deployable in Finland and more
exportable? How to prove that?
• Has new research capacity emerged? How to prove that?
• Has it resulted in better healthcare services to citizens?
How on earth will that be proved?!?”