"We have an expensive plethora of uncoordinated, unlinked, economically segregated, operationally limited micro systems " -George Halvorson, borrowed from opening speech by Marion Ball 1
HIS architectures for healthcare networks: Achieving adaptability for healthcare transformation? IMIA HIS Working Conference Franschhoek, 11 September 2010 Juha Mykkänen*, Mika Tuomainen, Hannu Virkanen * Health Information Systems R&D Unit School of Computing, Kuopio campus University of Eastern Finland juha.mykkanen@uef.fi 2
Speaker background Dr. Juha Mykkänen University of Eastern Finland, Kuopio researcher, School of Computing, Health Information Systems R&D Unit research line director, Kuopio Welfare Research Center KWRC vice chair in Finnish Social and Health Informatics Association, vice chair in HL7 Finland (co-chair common services & IHE SIG), HL7 SOA Ambassador IMIA WG HISs: Heidelberg 2002, Oeiras 2006, Fransschoek 2010 Projects developing and applying architecture and interoperability approaches in healthcare SOLEA: Agile Enterprise Architecture using SOA and BPM 2008-2011 SerAPI: SOA and integration of healthcare applications 2004-2007 OmaHyvinvointi (MyWellbeing): personal wellness management 2008-2010 PlugIT: healthcare application integration 2001-2004 ekat / guidelines for national ebooking of health services 2008 TJSERT / Certification requirements of national health IT services, 2008 Healthcare services specification project (HSSP) / HL7 and OMG, 2005- Integrating the Healthcare Enterprise - IHE.fi 2008- National project for social services IT - Tikesos 2006-2011 China/Finland ehealth partnership + other projects in Shanghai 2004-2008 Various HL7 Finland and web services standards implementation guides, 2004-2009 3
Outline Background and aims where we are history and motivation Approach and material analyzing five national-level projects using an enterprise architecture approach Analysis results of analysis Discussion challenges, generic lessons, are we getting there? 4
Background and motivation: where we are since 1980 s, partitioning HIS into subsystems and integration have been central themes in IMIA HIS conferences, extending towards healthcare networks and national / regional strategies continuity of care networked care models, healhcare networks health information exchanges, standards, interoperability increasing focus on prevention and self-care patient empowerment personal health records, personal health systems, ehealth, mhealth, uhealth services CHANGE: the pace of knowledge generation, process / organizational change and technology change keeps increasing components need to be easily updatable (clinical knowledge changes), adaptable (business requirements or processes change), exchangeable (technology advances) * enterprise architecture viewpoints to adaptability integration on syntactic, semantic, organizational and individual level * [Knaup et al. EPRs: Moving from Islands and Bridges towards Electronic Health Records for Continuity of Care, 2007] 5
Aims can we identify architectural and methodological building blocks of successful adaptable HIS architectures for healthcare networks and individual empowerment? what kind of lessons can we learn in terms of architecture, methods and governance? basis for discussion on how to achieve adaptable HISs as an enabler of transformation of health care 6
Approach of this study summarise an analysis of results and specifications from five national initiatives in Finland, related to healthcare networks 1. national eprescription interoperability specifications (HL7 CDA and version 3 implementation guides) - OpenCDA 2. specification of national certification requirements for eprescription - TJSERT 3. specification of national guidelines for ebooking of healthcare services ekat scheduling 4. specification of service events related to the management of national EPR SOLEA / service events 5. specification of citizen-centric architecure of (healthcare) eservices MyWellbeing / Coper discuss in relation to adaptability and governance challenges
Methods analysis of results from projects producing specifications for several implementation projects, using an enterprise architecture approach collection and analysis of specification subjects, architectural descriptions and projects structured analysis of specifications : business / application / technology levels*, 17 base categories of specification subjects harvesting relevant HIS solutions, observations and challenges in relation to: health service transformation (business viewpoint) coordination and traceability in multilateral and incremental initiatives adaptability aspects in primary enterprise architecture (EA) viewpoints service-oriented approach (e.g. SOA) manifested main successes observed main challenges * based on 3 architecture approaches with closely corresponding levels, (Archimate, Essential, Mykkänen et al. 2007), level names used from the Archimate EA standard. 8
Case examples
1 eprescription interoperability 21 89 2 certification requirements for eprescription 6 152 3 national guidelines for ebooking 13 54 description types subjects of specification 4 service events for the management of the national EPR 26 105 5 Coper architecture - citizen-driven eservices 16 46 0 20 40 60 80 100 120 140 160 10
1 eprescription interoperability the OpenCDA / eprescription project / HL7 Finland + Ministry of Social Affairs and Health MSAH Project goals: specify interfaces between the national eprescription centre and pharmacy / EPR applications Results analysed: HL7 CDA and version 3 messaging implementation guides (Medical records, CDA header, CDA body) Number of subjects of specifications / description types: 89/21 Other relevant observations: highly focused on uniform application of base standards for eprescriptions 11
Results: 1 eprescription interoperability Case summary Health service transformation Coordination and traceability EA + adaptability Service-oriented approach (e.g. SOA) Manifested main successes Observed main challenges Reduction of errors and counterfeits, improvements in dispensation and renewal processes, interoperability Clear functional and architecture specifications used as a basis, but several versions produced due to changes in them. Consensus acceptance process (voting). Strict interoperability and interface focus, little architecture adaptability. Little optionality. Not visible in specifications, but base architecture and implementation infrastructures use SOA features. Acceptance of specifications and successful implementation projects. Even minor changes in requirements and functional specifications must be reflected in technical specifications ( when to vote etc.?). Risk of mixing process and messaging details in MR specifications (control acts ). 12
2 certification requirements for eprescription the TJSERT project eprescription subproject / Stakes + MSAH Project goals: production of certification requirements for organizations and systems joining the national eprescription center Results analysed: main specification document and requirements catalogues for health service providers and pharmacies (in total 471 requirements in 148 subjects and 48 main functions) legislative, functional, information, technology requirements Number of subjects of specifications / description types: 148/ Other relevant observations: if original specifications had a more detailed conformance criteria, the project would have been more straightforward (focus on verification) or it would not have been needed at all! 13
Results: 2 certification requirements for eprescription Case summary Health service transformation Coordination and traceability EA adaptability Service-oriented approach (e.g. SOA) Manifested main successes Observed main challenges Reduction of errors and counterfeits, improvements in dispensation and renewal processes, uniform service level across implementations and deployments. Special emphasis on traceability of requirements to source documents, coordinates Focuses on requirements on many EA viewpoints. Aims to reduce optionality and increase uniformity. Not applied. A working model for certification, large number of verifiable requirements for implementations and deployments. Several versions of base legislative, functional and technical specifications during the project 29 versions of 13 base documents, delayed legislation (decree). Status of requirements has not been mandated. 14
3 national guidelines for ebooking of healthcare services ekat scheduling ekat Scheduling subproject city of Oulu + MSAH Project goals: guidelines and architecture for national and regional development of ebooking, (overall project): national coordination of six regional citizen eservice projects Results analysed: main result specification: Guidelines for the national architecture for ebooking of health services Number of subjects of specifications / description types: 54/13 Other relevant observations: local projects and previous integration efforts produced successful solutions to partial challenges such as integration of back-end systems to regional ebooking and laboratory scheduling for patients, but had significant differences in specific goals and approaches 15
Results: 3 national guidelines for ebooking Case summary Health service transformation Coordination and traceability EA adaptability Service-oriented approach (e.g. SOA) Manifested main successes Observed main challenges Citizen / patient empowerment, increased choice, automation of administrative tasks for providers Collection and harmonization of solutions from several projects, coordination of already initiated projects. Migration paths towards more advanced levels of citizen ebooking and implementation options on local / regional / national levels identified. adaptable national / regional / local architecture, 18 identified services with structured service descriptions Comprehensive architectural specification for segment architecture, Use of results in several further projects and implementations. Post-coordination of projects gathering and merging results from projects but heterogeneity remained. 16
4 service events for the management of the national EPR SOLEA: enterprise architecture and SOA, cases from industry and healthcare, two Finnish universities, consortium of hospital districts, industry user organizations and system vendors Project goals: service events subproject collected and clarified the concept, architecture and management of service events: a central concept in the management of documents and patient consent in the national EPR from a local viewpoint (local EHRSs, departmental and regional systems) Results analysed: main specification, 107 pages Number of subjects of specifications / description types: 105/26 Other relevant observations: the used enterprise architecture approach for segment architectures is reflected in specification which contains two iterations of the EA development process cross-mappings between functions and roles were seen especially useful 17
Results: 4 service events for the management of the national EPR Case summary Health service transformation Coordination and traceability EA adaptability Service-oriented approach (e.g. SOA) Manifested main successes Observed main challenges Clarified linkage of medical document entries and activities, possibility for patients to see their own medical data from the providers from national EPR Starting point: trace, harmonize and clarify service event specifications from various national specifications. Coordination with other national initiatives related to the national EPR archive. Focus: application level. Many local options in terms of application responsibilities (design option catalogues). 11 SOA services / application roles and their mapping to functions, responsibilities and implementation levels Clarification of service event management, very quick use of results in related projects (interfaces, architecture). Unclarities and contradictions in base documents and their interpretations, change of the national consent management model during the project. 18
5 Coper architecture - citizen-driven eservices the MyWellbeing project, 6 universities and a consortium of health service provider organizations and systems vendors in Finland, two case groups of citizens Project goals: Coper: a holistic concept for citizen-driven management of wellbeing information, architecture subproject: the functional service architecture for the Coper Results analysed: the main architecture deliverable, 70p Number of subjects of specifications / description types: 46/16 Other relevant observations: turn-around of traditional information management model: individual ownership and empowerment as the major driver close correspondence with Personal Health Records and Personal Information Management models 19
Results: 5 Coper architecture - citizen-driven eservices Case summary Health service transformation Coordination and traceability EA adaptability Service-oriented approach (e.g. SOA) Manifested main successes Observed main challenges Individual empowerment, integration of heterogeneous (types of) eservices for citizen Traceability between individual and community needs and various types of services from different providers Focus: application level. Enterprise around individuals, architecture must be adaptable but provide integrated view to individual 62 services in seven main categories, selection of relevant standards for some integrations Truly citizen-driven view of services, extensible and integrated services framework concept. heterogeneous business models for health service providers, non-integrated offering of existing services, variations of integrator and payer responsibilities 20
Observations and results from case examples all focused to support multiple implementation and deployment projects all focused on some segments / aspects, not holistic enterprise architecture a degree of local autonomy in healthcare networks but strict enforcement of interoperability contracts enforcement problem of collaborative projects: mandate to take results forward is sometimes driven by authorities, sometimes by local or regional organizations, sometimes by commercial interests, (and often times divided between these or unclear) SOA approach enables gradual migration in different local contexts or upon changing national or local priorities how many corrections and iterations could we avoid by putting more effort to the early phases of the process and traceability? using knowledge in literature and standards, internationally and across disciplines (Body of knowledge) agreeing, documenting and communicating the shared goals prototyping and early table testing with users 21
Conclusions How does each design decision help us achieve the service transformation traceability (beyond single projects) What is required for adaptability? design for unforeseen + reuse: service-oriented approach promotes extensibility integration: goal-driven architectural decisions (chaos is adaptable ) agreement on multiple levels of interoperability use of open technologies, open standards, semantics, activity networks transition from project-centric mindset towards incremental improvement What is required for governance? shared architectural frameworks, rules, standards, and their enforcement collaborative governance usually no central mandate for all aspects of the networked enterprise architecture - how can we reach consensus faster? We are getting there however, to do our work efficiently we must apply industry best practices where possible but with caution: industrial process automation seldom fits healthcare activities can we reduce overlapping specification and description types of same elements?
Conclusions How does each design decision help us achieve the service transformation traceability (beyond single projects) What is required for adaptability? design for unforeseen + reuse: service-oriented approach promotes extensibility integration: goal-driven architectural decisions (chaos is adaptable ) agreement on multiple levels of interoperability use of open technologies, open standards, semantics, activity networks transition from project-centric mindset towards incremental improvement What is required for governance? shared architectural frameworks, rules, standards, and their enforcement collaborative governance usually no central mandate for all aspects of the networked enterprise architecture - how can we reach consensus faster? We are getting there however, to do our work efficiently we must apply industry best practices where possible but with caution: industrial process automation seldom fits healthcare activities can we reduce overlapping specification and description types of same elements?
How does each design decision help us achieve the service transformation traceability (beyond single projects) are your lights on? Kiitos juha.mykkanen@uef.fi The authors would like to express their gratitude to all the members and participants of the following projects: Open CDA projects / HL7 Finland the TJSERT project, especially Pekka Ruotsalainen the ekat coordination and escheduling project, especially Anne Niska the SOLEA project participants, especially service event subproject the MyWellbeing (OmaHyvinvointi) project