DIGITAL SERVICES FOR CITIZENS

Transcription

1 DIGITAL SERVICES FOR CITIZENS Stefano Lotti HL7 International SOA WG Co-Chair (HSSP) HL7 Italia CTO Bressanone XXXVI Scuola Annuale di Bioingegneria settembre 2017

2 HL7 International Founded in 1987, Health Level Seven International (HL7) is a not-for-profit, ANSIaccredited standards developing organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services. Functional Models (e.g. EHR-S, Vital Sign, etc.) FHIR resource HL7v3-CDA 2 HL7 v2 Contenuti API HL7 is supported by more than 1,600 members from over 50 countries, including 500+ corporate members representing healthcare providers, government stakeholders, payers, pharmaceutical companies, vendors/suppliers, and consulting firms. SOAP FHIR (REST) Servizi

3 Italian Environment The organization of Italian Healthcare system is substantially federal. Each Region and Autonomous Province, in the healthcare domain, can be viewed close to a State. The central government assigns a budget to each Region and each Region should conform itself to a series of Common Levels of Assistance (LEA). This organization of Italian healthcare is obviously reflected in the evolution of National EHR (aka FSE ) architecture. This is consistent with the meaning of so called Conway Law. The Law observe that the software interface structure of a system reflect the social boundaries of the organizations that produced it.

4 The Conway Law Conway Law «organizations which design systems... are constrained to produce designs which are copies of the communication structures of these organizations.» (Melvin E. Conway, "How do Committees Invent?", Datamation, 14 (5), 28 31, April 1968) Must be underlined that this is not just a consequence of an (e.g.) Italian administrative aspect, it reflect the distributed nature of health system.

5 Ultra-Large-Scale Systems «there can be no centralized control; no one can ever know all requirements; requirements will inevitably conflict; the system will always be both in production use and under construction; the distinction between system and user no longer makes sense: people are part of the system; localized failure is commonplace and not systemically harmful, yet there are critical points of systemic vulnerability and risk that must be treated with utmost care; ULS systems will inevitably be constructed on top of, or out of, already vastly complex legacy computing systems and institutions; traditional approaches to design and acquisition do not work.» Kevin Sullivan - William Knaus - Richard Marks, An Ultra-Large-Scale Systems Approach to National-Scale Health Information Systems, Proceedings of Conference SIGSOFT/FSE'10 18th ACM SIGSOFT Symposium on the Foundations of Software Engineering (FSE-18), Santa Fe, NM, USA November 07-11, 2010

6 Fist plan (2006) These intrinsic characteristics shaped the architecture of the National EHR (FSE) since the initial effort defined by the document: Architectural Strategy for Electronic Health This first architecture (2006) plan the use of an advanced peer to peer architecture to distribute index of documents and data among Regions. In this first effort, several pilot projects at were funded by central government in region of south of Italy. Even if in these projects, the interregional interoperability is not effectively defined, the TSE produced the interface for registryrepository. The specification was realized with the support of MDA technique In parallel, other regions develop, independently, a local EHR infrastructure. In subsequent years, some experiment of interregional interoperability was made but no coordinate effort was committed.

7 Second step (2012) In 2012 the landscape change with the formalization by law of regional interoperable EHR. A series of subsequent acts and regulations give a new boost to the realization of a nationwide EHR. Even if a fully coordinate governance isn't fully implemented a new series of activity was launched. The resulting architecture is a simplification of the old one. Each region maintains the index of His patients even if the document is in another region so, knowing the patient and his region of assistance, it s possible to locate all the patient documents without the use of a per to peer network. In the first implementation is requested the interoperability of 2 document (Patient summary and Laboratory report). The documents are based on HL7 CDA 2 and the Implementation Guide is standardized by HL7 Italia. The architecture support correctly the initial use case defined by the regulation. However, Region and central administration was rapidly aware that an EHR cannot be reduced to document interchange. So, Regional Administration and some national entity work on a more comprehensive vision of EHR.

8 Beyond the documents interchange (2013) The architecture support correctly the initial use case defined by the regulation. However, Region and central administration was rapidly aware that an EHR cannot be reduced to document interchange. So, Regional Administration and some national entity work on a more comprehensive vision of HER: EHR cannot be considered an application, it s a complex set of functions realized by several organization ad software. The design of a real EHR cannot be realize day by day, document by document, a discussion and an identification of a common set of function cannot be avoided. To achieve a real interoperability is necessary to have a functional coherence among different implementation. At the end of the day the national interoperability is not a primary objective, the objective is the interoperability among human and computer. The focus are the functions of the system. In this context, an HL7 Standard: The Electronic Health Record System Function Model (R2) has been used as a base to realize a specific Italian Profile. Substantially, the EHRS Functional Model profile is a systematic function list that a specific EHRS type should support.

9 EHR-S FM Profile for Regional EHR: The FSE- FM Group In February 2013 HL7 Italy with a bunch of Regional Administration and other public institutions promoted an interregional group with the objective of defining a common functional model for regional EHR system The participants of the FSE-FM Group increased over time and currently include: 19 Regional Administrations (out of 21), 15 Regional Agency and Health Authority, 3 National public entity (INVITALIA, CISIS and CNR-ICAR) and, obviously, HL7 Italy 9

10 EHR-S FM Profile for Regional EHR ( ) Functional Profile of Regional EHR (FSE) White Paper The realized Functional Profile (in 9 moths) has been published as an HL7 Italy White Paper and adopted by the mandatory National Guideline for EHR planning published by the Agency for Digital Italy (AgID) and the Health Ministry as the basis for implementations and interoperability. \ Functional Profile extract for «first enforcement» Immediately after the first the publication the formal standardization process in HL7 Italy has been started The revision activity included: o o o Formal revision of the profile (EHR-S FM rules) EHR-S Glossary full translation and extension Linguistic alignment Functional Profile of Regional EHR (FSE) STU In April 2016 the STU standard has been released by HL7 Italy

11 Beyond the basic functions The Group also identify the functions subset prescribed or implied by the Regulation in the first implementation step. The current basic interface support the necessary operation for document interchange and identification but this is clearly not enough in the medium term. The effort realized by the group of regions is the first step in a real National Architecture.

12 Must be done An example of the next step: "A dream? Health spending control: understanding which doctors insist on prescribing branded drugs instead of generic ones. (2017) imply imply imply Semantic content (i.e. IG CDA2 and/or FHIR Resource) Terminology (i.e. SNOMED(?), IDMP (?), ATC, UCUM ) Services (i.e. Provider Identification, Patient Identification, Ordering Service, Terminology ) SOAP and/or FHIR (REST) tecnology

13 Reference Architecture Simultaneously with the trial of basic interoperability, the EHRS functional model profile can serve as a basis for planning the evolution of the system. The list of function should be mapped on an Inventory of services. In this way is possible to identify, specify and plan an architecture in a meaningful way So, in this context, a Reference Architectures can be used as a base for an executable strategic map on the function of Nationwide EHR (FSE).

14 Reference Architecture elemen Business Services (e.g. Based on EHRS-FM Composite Sevices (coordinating) Enabling Services Semantic content/signifier Infrastructure

15 The Services Landscape

16 The current italian national landscape Currently the effort is mainly on semantic content specification based on HL7-V3-CDA2. It s the basis for a most comprehensive document interchange The national interoperability, consequently, have an initial basic architecture, based on document interchange. Now: How can evolve the system, as a whole? How can evolve, currently, the systems at the regional level? Enabling Services Record RLUS XD* Suite (inspired by) FHIR Restful trasport Semantic content/signifier FHIR Resources HL7V2 HL7V3-CDA2

17 Why a Reference Architecture? Basically a Reference Architecture «provides a template solution for an architecture. It also provides a common vocabulary with which to discuss implementations, often with the aim to stress commonality.» (Wikipedia) It support the response to some basic questions: What have we done? What can we do?

18 Business Services Population Health Composite Services (Coordinating) Enabling Services Semantic content/signifier Infrastructure Care coordination Care Coordination Svc PCC Terminology Services CTS2 SVS Identity FHIR Resources ESB (COTS/OSS) IXS PIX/PDQ Scheduling Services Scheduling Svc Electronic Health Record (EHR/EMR) Record RLUS XD* Suite Order Ordering Svc Health Services Directory ServD HPD HL7V3-CDA2 Personal Health Record Event FHIR Restful trasport Health IT Sevices Reference Architecture V. 2.0 draft Cohort Event PUB/SUB Cohort Mgmt Svc Unified Comunication UCOMMS Svc Clinical Decision Support CDS Svc Security Services Clinical Quality HL7V2 Service Discovery (e.g. UDDI) Autentication Autorization... PASS Audit PASS Access Control ATNA XUA Task Task Mgmt Svc Data mapping and trasformation CrossParadigm Model Driven Message Interoperability (MDMI) Archetype Modeling Language (AML) Business Services Population Health Composite Services (Coordinating) Infrastructure Care coordination Enabling Services Care Coordination Svc PCC Terminology Services CTS2 SVS Semantic content/signifier Identity FHIR Resources ESB (COTS/OSS) IXS PIX/PDQ Scheduling Services Scheduling Svc Electronic Health Record (EHR/EMR) Record RLUS XD* Suite Order Ordering Svc Health Services Directory ServD HPD HL7V3-CDA2 Personal Health Record Event FHIR Restful trasport Health IT Sevices Reference Architecture V. 2.0 draft Cohort Event PUB/SUB Cohort Mgmt Svc Unified Comunication UCOMMS Svc Clinical Decision Support CDS Svc Security Services Clinical Quality HL7V2 Service Discovery (e.g. UDDI) Autentication Autorization... PASS Audit PASS Access Control ATNA XUA Task Task Mgmt Svc Data mapping and trasformation CrossParadigm Model Driven Message Interoperability (MDMI) Archetype Modeling Language (AML) Ingredients and cooking recipe (example) General Health Reference architecture Current regional Architectures and National objectives Mapping Italian Health Reference architecture Transition Plan Profilo Funzionale Fascicolo Sanitario Elettronico (FSE) Regionale Use Case Infrastructure development A Reference Architecture is a critic ingredient to facilitate a meaningful and cost effective system development.

19 Reference Architecture effort in HL7 International HL7 International have an ongoing effort to complete a Reference Architecture and the Italian example is a clear illustration of its relevance. Avoid accidental architectures and to have a sound design, control and meaningful planning are the objectives The Winchester House ( Mystery_House)

20 Health Reference Architecture Outcomes The project aims to organizes HL7 Service Functional Models, Functional Profiles and Domain Models into: a formalized Enterprise Service Inventory an Architectural Patterns Catalog associated methods for enterprise Service discovery and orchestration The projections of specific technology/standard service implementations (FHIR, OMG/HL7 Soap services, IHE XD* family) will be discussed

21 Service Architecture HL7 Health Service Reference Architecture [DRAFT V3] Business Functions Leggend: Business Function Application Services Application Interface HL7/OMG IHE Application Interaction Future Services Ongoing or STU Population Health Electronic Health Record (EHR/EMR) Personal Health Record Clinical Quality Composite Services (Coordinating) The diagram sketches the (draft) Reference Architecture/ Service Inventory Each service can have tree projection in: FHIR/REST, HL7-OMG WS* IHE-XD* profile Application service A Business function X Application service B Care coordination Care Coordination Svc PCC Enabling Services Terminology Services CTS2 SVS Semantic content/signifier Identity IXS PIX/PDQ Scheduling Services Scheduling Svc Record RLUS XD* Suite Health Services Directory ServD HPD Order Ordering Svc FHIR Restful trasport Event Event PUB/SUB FHIR Restful trasport Cohort Cohort Mgmt Svc Unified Comunication UCOMMS Svc Security Services FHIR Resources HL7V2 HL7V3-CDA2 PASS Audit PASS Access Control ATNA XUA Clinical Decision Support CDS Svc Data mapping e trasformation CrossParadigm Model Driven Message Interoperability (MDMI) Archetype Modeling Language (AML) Infrastructure Enterprise Service Bus (COTS/OSS) Service Interface A Service Interface B Application interaction Service Discovery (e.g. UDDI) Autentication Autorization Workflow Engine...

22 Formalized Enterprise Service Inventory «A service can be seen as a container for a collection of related functions.» «A service inventory is an independently standardized and governed collection of complementary services within a boundary that represents an enterprise or a meaningful segment of an enterprise.» (Thomas Erl) The basic Idea is to organize and reconsider the HL7 service inventory (mainly based on HL7 Service Functional Models) For each service the relevant implementable projections (FHIR, SOAP, XD* ) should be individuated Must be underlined that an, implicit, HL7 Services Inventory exist, but it's dispersed in several documents and specification.

23 Architectural Patterns Catalog A service, in the real world, do not live alone, it s combined in architectures (of cooperating components that expose services). In a Reference Architecture, we should individuates and describes Architectural Patterns as general, reusable solutions to real world occurring problems in software architectures The inventory previously sketched in the Catalog will be combined in patterns that describe solution at business problem As a basis for pattern definition the OMG Standard: Structured Patterns Metamodel (SPMS) should be used.

24 Example: A scenario and services mapping Identit y Mng. Recor d Mng Order Mng Care Coord. Data Map.

25 Patterns general structure The diagram is a simplified fragment of SPMS. It s useful to understand the patterns basic structure and how it s related with the Inventory

26 Associated methods for enterprise Service discovery and orchestration Methods for discoverability and orchestration are, obviously, critical aspects for medium/large scale architectures. Reference Architecture, per-se, will support these aspects at conceptual and design levels. Patterns Catalog describe useful choreographies of services and the Service Inventory improve discoverability. However this is not enough: at patterns instance (implementation) specific methods and strategies should be defined. E.g. WS* and REST requires slightly different approach, technologies and standards for orchestration and service discoverability.

27 Again: why a Reference Architecture? Moreover/1: must be considered that even if the work is not completed an RA, implicitly, exist Moreover/2: must be considerer that the risk of an accidental architecture is in place and cannot be seriously ignored The Winchester House ( Mystery_House)

28 Grazie per l attenzione

29 The Healthcare Services Specification Program The Healthcare Services Specification Program (HSSP) is an open, global community focused on improving health interoperability within and across organizations through the use of Service-Oriented Architecture (SOA) and standard services. The intention is to reduce implementation complexity, promote effective integration, foster marketplace support, and drive down implementation costs and barriers impacting healthcare solutions. HSSP is also a joint standards development activity occurring in multiple organizations, including Health Level 7 (HL7), Object Group (OMG) and in future with Healthcare Services Platform Consortium (HSPC), and others