290 likes | 398 Views
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
E N D
PlugIT’s closing seminar, Kuopio, 30 Aug 2004 Updated 2 Nov 2004 PlugIT in a nutshellPlugIT: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 mikko.korpela@uku.fi 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 – 1Initial 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 – 2Government 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 developmentproject to produce (1)openapplication program interface (API) specifications as well as related (2)methods and (3) expertise forhealthcare 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 • Intra-activity: e.g. electronic record – scheduling; PlugIT’s focus • Between activities within an organization: caredept. – service dept.; HL7 messages • Between activities along a service chain: e.g. referral – feedback, ”disease mgt systems”; HL7 • Choice of services between organizations: regionalinformation systems, portals • eGovernment/Business: eHealth, citizen’s records
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.
Healthcare software service chain:How integration research will improve services
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 MikkoKorpela, 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, MicrosoftOy, 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 electronicpatientrecordsystems • Projects on regional information systems • Sonetti partnership by hospital districts in Eastern Finland • Health Kuopio programme
Approach – 1:Progressing from two directions International standards HL7, OMG Healthcare Domain Task Force (ex CORBAmed), CEN/HISA, ISO 215, IHE, HIPAA, … 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 Healthcare process improvement initiatives Macro Pilot Project, Sonetti, Pirke, National Healthcare Project, …, …, … Proprietary and two-party solutions …, …, … Top down Bottom up
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 • October 2001 – April 2002: Evidence for funding decision • Recruitment, elaborating on the plans, gathering the consortium, raising funding for the main phases • May 2002 – October 2002: Foundations laying • Meetings with partners, surveys, self-education • 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 • 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 • November 2003 – April 2004: Models, methods • Reference implementations, push to pilots, systematization of methods, new project proposals • May 2004 – August 2004: Packaging • Fine-tuning, documenting, publicizing the results
Results 1: Interface specificationsTwo 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 specificationsSolution 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.
Results 1: Interface specificationsSolution 2: Common services 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. When e.g. a patient’s personal data are modified via one application, all other applications will ”see” the change immediatelly. All applications’ common code sets are updated from the national terminology server. Maintenance will decrease.
Results 1: Interface specificationsAPIs as a part of the national set of means • 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: MethodsIntegration specification process Mykkänen et al., MEDINFO 2004
Results 2: MethodsFrom a ”gray area” to software requirements Toivanen et al., AT in IT Design 2004
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” – ~10products in the market which could potentially act as servers (health centre systems, HIScore 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 serviceproviders – 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)? Howcanthat 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?!?”