HL7v3 CDA Rel.2 Patient Summary and Chronic Care Model: Localization Experience and GP/HS Integration Project

Transcription

1 HL7v3 CDA Rel.2 Patient Summary and Chronic Care Model: Localization Experience and GP/HS Integration Project Renato Calamai ehealthtech Via delle Cantine Calenzano (FI) - Italy renato.calamai@ehealthtech.it Laura Giarré Dias-Università di Palermo Viale delle Scienze Palermo - Italy giarre@unipa.it Abstract The localization experience for the Patient Summary, based on the Health Level Seven Version 3 (HL7v3) Clinical Document Architecture, Release 2 (CDA Rel.2), is presented. An overview of the Chronic Care Model (CCM) is introduced with particular attention to the clinical information systems, in order to organize patient and population clinical data by sharing information among healthcare providers in management of chronic diseases. We propose, as case study, a project for the integration of various services for General Practitioners (GP) and Hospital Specialists (HS), accessing the Electronic Health Record (EHR), implementing the Patient Summary and managing the exchange of Chronic Care medical records. This project is in line with the state of the art in the normative referring context for the Italian healthcare, both at national and regional level (Tuscany Region). Index Terms e-health, HL7, Interoperability, Chronic Care Model, Patient Summary, EHR I. INTRODUCTION New challenges in healthcare should be based [1], [2] on a rationalization of administrative and managerial processes; an improvement of the clinical and healthcare processes; a reduction of clinical risks; and an expanded Chronic Care Model (CCM) [3] in order to overcome the deficiencies in current management of chronic disease. The Italian healthcare situation is characterized by an huge diffusion of heterogeneous ad hoc applications and legacy systems in all the administrative and clinical domains; a very low presence of advanced solutions (Service Oriented Architecture and Business Process Management); deficiency of guidelines both at regional and national level; and, finally, lack of applications based on technological standards. One of the solution is the use of innovative standards for the integration of the information systems and the implementation of application solutions based on modern technological standards. The use of standard enables the interoperability. Interoperability is the ability of two or more systems or components to exchange information and to use the information that has been exchanged. We will refer to HL7v3 [4] as the most widely used standard for healthcare interoperability. The Patient Summary (in Italian Profilo Sanitario Sintetico (PSS)), an electronic clinical document summarizing the most relevant clinical information facts about a patient s healthcare, represents one of the main elements of the Electronic Health Record (EHR) systems. The integration of the Clinical Information Systems, between hospital and primary care is one of the essential aspects of the Chronic Care Model, as reported in [5] for Tuscany Region, for the development of diagnostic and therapeutic paths Percorsi Diagnostico Terapeutici Assistenziali (PDTA). In a recent FIASO (Federazione Italiana Aziende Sanitarie e Ospedaliere) report [6] an optimistic picture of the Italian situation is overviewed with regards to the knowledge of the EHR (71% of GPs and 67% of HSs) and a spread use of EHR and Patient Summary reported as 7 regions among 20. The paper is organized as follows: in the following we present the referring normative and technological context with a brief overview of the standard HL7v3 for the Clinical Document Architecture (CDA) Rel.2, and the Chronic Care Model for the Clinical Information Systems; in section II we describe the experience with the CDA Rel.2 localization for Patient Summary and in section III the experience in implementing the CCM medical record; in section IV we describe a project of Integration for General Practitioners (GP) and Hospital Specialists (HS), accessing the EHR, implementing the Patient Summary and managing the exchange of Chronic Care medical records; and, finally, in section V we draw some final remarks. A. Referring normative and technological context The referring context for Italian e-health is primarily described in the project of the Health objective for the Italian plan e-gov 2012 [7], including the project Medici in Rete for the connection of the General Practitioners and the Pediatricians with the regional infrastructures; and the project Fascicolo Sanitario Elettronico (FSE) for the implementation of a distributed solution for patient s EHR (in Italian FSE), at regional, national and European level. The technological references have been published by the Tavolo permanente di Sanità Elettronica (TSE) composed by the regional representatives, and coordinated by the Department Digitalizzazione e Innovazione Tecnologica of the Innovation and Public Administration Ministry (Ministero della Pubblica Amministrazione e Innovazione), with the participation of the Health Ministry 147

2 (Ministero della Salute) and DigitPA. These documents are related to architectural strategies for e-health; the regional EHR guidelines [8]; the definition of the national EHR technological infrastructure (InFSE) [9]; and the technical specifications of the electronic Medical Report, according to the standard HL7- CDA Rel. 2, for the exchange of clinical data at national level [10], [11]. According to these projects, and also to Progetto Mattoni SSN (Servizio Sanitario Nazionale) Realizzazione del Patient File [12], HL7 Version 3 has been indicated as the messaging standard in healthcare information exchange, and HL7-CDA Rel. 2 as the standard for clinical documents exchange. The IHE-XDS profile (Cross-Enterprise Document Sharing) is also suggested as one of the reference framework for registering and sharing electronic health record documents between healthcare enterprises [13]. In the present work, we mainly focus on the Patient Summary that is an important aspect in the GP systems integration with the EHR. In the past, TSE started various regional projects for the General Practitioners [14] Sanità Elettronica - Rete dei Medici di Medicina Generale, including the Patient Summary, the electronic clinical document summarizing the most relevant clinical information facts about a patient s healthcare, to support the continuity of care. Patient Summary is a document of the EHR that must be created, updated and digital signed by the GPs providing a snapshot in time containing the pertinent clinical data, as the emergency data set. Patient Summary is developed according to the standard CDA Rel. 2 and is based on the HL7 Continuity Care Document (CCD), a CDA implementation of ASTM Continuity of Care Record (CCR) [15]; the IHE Patient Care Coordination (PCC) [16]; and [17],[18],[19],[20]. The need to identify synthetic and effective tools to facilitate the sharing of information between the various actors involved in the process of care and assistance of a patient has been recently increased at international level (see Belgium (SUMEHR), England (Summary Health Record), Sweden, Finland (Patient Core Data Set), U.S. (Continuity of Care Record), Canada). In Italy, up to now, the standard for the Patient Summary CDA Rel.2 has not been yet delivered. The TSE is working on a draft document for the definition of the Patient Summary, based on the indications resulting from the various regional projects Medici in Rete, among which the CR SISS Regione Lombardia [21] LUMIR Regione Basilicata [22], RMMG Regione Abruzzo [23]. In Tuscany Region, Patient Summary is defined in the RFC 133 [24], according to [25]. The exchange and sharing of clinical information in chronic illness is an other important aspect of the GP Integration Project with the Hospital Specialist. The integration of the Clinical Information Systems, with particular attention to the GP Medical Records with the Hospital Specialist Medical Records represents one of the essential elements in implementing the Chronic Care Model (CCM). This aspect is in line with the development of a proactive healthcare that is based on an integrated management of the diagnostic and therapeutic paths (PDTA) between hospitals and primary care with the community-based facilities and services. The normative referring context at Tuscany Region level is the Piano Sanitario Regionale (PSR) [5], specifically the objectives of proactive healthcare and the Chronic Care Model; the various bylaws of Regional Health Department [26], [27],[28]; and the opinions of the Regional Council Health Committee [29], [30], [31]. B. HL7 Version 3 CDA Rel.2 Health Level Seven International (HL7) is the leading global authority for healthcare information interoperability and standards with members in over 55 countries. HL7 is "an ANSI accreditated standard development 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" [4]. HL7 Version 3 (HL7v3) is a reference paradigm for the syntactic-semantic interoperability. The HL7 V3 methodology uses the Reference Information Model (RIM), the Data Types Specification, and the HL7 Vocabulary as its starting point. It then establishes a message development process for refining and constrain the Reference Information Model to arrive at the Hierarchical Message Descriptor (HMD) that specifies a number of messages called Message Types. The following Figure 1 shows the refinement process specified in the methodology. As diagrammed, the processes are used to derive one or more Domain Message Information Models (D-MIM) from the RIM. Each such model represents the set of concepts embodied in the individual Refined Message Information Model (R-MIM) needed to represents the requirements of a particular HL7 domain. Fig. 1. Refinement Process for defining messages based on the HL7 RIM (Source: Health Level Seven, Inc.) The HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of clinical documents for the purpose of exchange. CDA documents are encoded in Extensible Markup Language (XML). A CDA document is wrapped by the <ClinicalDocument> element, and contains a header and a body. The header lies between the <ClinicalDocument> and the <structuredbody> elements, and identifies and classifies the document and provides information on authentication, the encounter, the patient, and 148

3 the involved providers. The body contains the clinical report, and can be either an unstructured blob, or can be comprised of structured markup. A CDA document section is wrapped by the <section> element. Each section can contain a single narrative block, and any number of CDA entries and external references. The CDA narrative block is wrapped by the <text> element within the <section> element, and must contain the human readable content to be rendered. C. Chronic Care Model The Chronic Care Model summarizes the basic elements for improving chronic illness care in health systems at the community, organization, practice and patient levels. This model, elaborated by Prof. Wagner of the Mac-Coll Institute for Healthcare Innovation [3], [32], identifies the essential elements of a health care system that help high-quality chronic disease care, such as diabetes, heart disease, hypertension, chronic obstructive pulmonary disease. These elements are - Community resources - Organization of Health Systems - Self-management support - Delivery system design - Decision support - Clinical information systems In Figure 2, the model is depicted with reference to the six main elements and their interactions. The improved outcomes Fig. 2. Care Model (Source: The MacColl Institute - ACP-ASIM Journals and Books) of this model are productive interactions between an informed and activated patient and a prepared and proactive multiprofessional health care team. Informed patients have sufficient information to become a wise decision-maker related to their illness and they also need to be activated by understanding the importance of their role in managing the illness. A prepared team is a practice team that is organized, trained, and equipped to conduct productive interaction. A productive interaction is one that assures that patient needs for evidence-based clinical and behavioral care information and support to become better self-managers, and monitoring over time are met, as reported in [3]. Clinical information systems are the crucial factor in improving chronic illness care with their clinical database containing the critical information necessary to get productive interactions. The fundamental functions to be guaranteed are: providing reminders and alerts for providers and patients; identifying relevant patient subpopulations according to their chronic illness for proactive care; facilitating individual patient care planning; sharing information with providers and patients; and, finally, monitoring performance of team with respect to the chronic care illness indicators. The Chronic Care Model will require a transformation of health care, from a system that is essentially reactive - responding mainly when a person is sick - to one that is proactive and focused on keeping a person as healthy as possible. This model has been promoted by the World Health Organization [33] and exploited in many countries such as Canada, Holland, Germany, United Kingdom, Denmark. In Tuscany Region this model has been used as the basis for the Expanded Chronic Care Model [34],[35] where the single patient takes a more informed role inside the community and where the General Practitioner clinical aspects are integrated with those of the public health. II. AN EXPERIENCE IN LOCALIZING THE CDA REL.2 FOR PATIENT SUMMARY Localization is the process of defining new HL7 Version 3 Message Types by a process that includes both the constraint process and an extension process that adds new concepts to the base Message Type. Any local HL7 affiliated organization needs to adapt the standard to the national or regional requirements. We report hereafter a brief summary of the experience of localization carried out with HL7 Italia, in the V3 Domain Working Group - Gruppo di Progetto HL7 Italia IG CDA2 Profilo Sanitario Sintetico. Within this experience, the document Implementation Guide Clinical Document Architecture (CDA) Rel. 2 Profilo Sanitario Sintetico (IT Real) is actually under discussion [25],[15],[16], [36]. Through the Patient Summary, the GP supplies a patient overview with a synthesis containing the only relevant data and let it available to the EHR. The principal aims of the PSS will then be the following: let the information be available for the emergency; help the chronic care processes; ensure the continuity of care. The PSS is a document satisfying some requirements: - it must be synthetic and contain only the essential information; - it must have a single author, the General Practitioners/- Pediatricians creating and updating it; - it is not clinically specialized to be used in different scenarios (Emergency, Chronic Care,..); - it does not have a specific predefined recipient; - it must be only one and there must be only one PSS for each patient inside the EHR. The compliance requirements of Patient Summary are based on the CCD, the IHE Patient Care Coordination and the Italian (IT) realm templates. The templates define the constraints for document, section, clinical statement and entry levels. Moreover the header must be compliant with the CDA Rel. 2 Header as defined by HL7 specifications and localized by HL7 Italia 149

4 CCD Section Purpose Payers Medical Equipment Immunization Vital Signs Results Procedures Encounters Plan of Care Advance Directives Functional Status Problems Family History Social History Alerts Medications History of Pregnancies Requirements SHALL NOT SHALL NOT RECOMMENDED RECOMMENDED SHALL NOT REQUIRED REQUIRED REQUIRED TABLE I LIST OF REQUIREMENTS FOR THE INCLUSION OF THE CCD SECTIONS (SOURCE: HL7 ITALIA) [36]. Patient Summary also follows the coding specification defined in the HL7 Italia document Identificazione Object Identifiers (OID) [37]. Patient Summary has been defined according to the CDA R-MIM. It is structured in a Header and a CDA Body, human readable (level 2) and machine readable (level 3). The CDA Body, structured in specific sections, contains the patient clinical data. The various elements <section> in the body may contain more than one element of type <entry> that could be narrative or partially/totally coded. Hereafter, we assume that the information contents of the coded entry will always be reported also as text in the narrative block. Not all the CCD sections have been implemented in the CDA Body. Table I reports which section is required, optional or not required, up to now. We report the CCD sections that are now under discussion in the Patient Summary localization. Alerts: section collecting alarms relative to any allergies, adverse reactions, and alerts that are pertinent to the patient s current or past medical history. Medications: section collecting all the actual prescribed pharmacological therapies. At a minimum, the currently active medications should be listed, with an entire medication history as an option, particularly when the summary document is used for comprehensive data export. Immunizations: section defining a patient s current immunization status and pertinent immunization history. The section should include current immunization status, and may contain the entire immunization history that is relevant to the period of time being summarized. Problems: section deputed to summarize the relevant clinical problems, including the main pathologies. At a minimum, all pertinent current and historical problems should be listed. CDA Rel.2 represents problems as Observations. Family History: section collecting the family medical history, relevant for the patient risks. This section contains data defining the patient s genetic relatives that have a potential impact on the patient s healthcare risk profile. Social History: section containing the patient s occupational, personal (e.g. lifestyle), social and environmental history. Social history can have significant influence on a patient s physical, psychological and emotional health and wellbeing. In the following, the CDA body for Alerts and Medications sections are reported as an example of localization. Alerts The information related to allergies and pharmacological reaction are listed in the section named with the LOINC code (Allergies, adverse reactions, alerts). The general structure of the Alerts section is reported in Figure 3. <component> < s e c t i o n > <templateid root = / > < t e m p l a t e I d r o o t = / > < t e m p l a t e I d r o o t = / > <id root= $ID_SEZ / > <code code= displayname= Allergie, Reazioni Avverse, Allarmi codesystem= codesystemname= LOINC / > < t i t l e > A l l e r g i e, I n t o l l e r a n z e ed A l l a r m i < / t i t l e > <text > $NARRATIVE_BLOCK < / t e x t > <! Molteplicità 1..N Problem Act > < e n t r y > $ALERT < / e n t r y > < / s e c t i o n > < / component> Fig. 3. Alerts: general structure of the section (Source: HL7 Italia) The information regarding an alarm is represented through an act derived from the template "Allergy and Intolerance Concern". The general structure of the entry Alarm is reported in Figure 4. < a c t c l a s s C o d e = ACT moodcode= EVN > < t e m p l a t e I d r o o t = / > < t e m p l a t e I d r o o t = / > < t e m p l a t e I d r o o t = / > <! specifica r e s t r i z i o n i aggiuntive specifiche di questa guida > < t e m p l a t e I d r o o t = / > <id root= $ID_SEZ / > <code n u l l F l a v o r = NA / > < s t a t u s C o d e code= $STATUS_CODE / > < e f f e c t i v e T i m e > <! RICHIESTO > <low ( v a l u e = $LOW_TS n u l l F l a v o r ="UNK" ) / > <! OPZIONALE > < high v a l u e = $HIGH_TS / > < / e f f e c t i v e T i m e > <! UNA SOLA e n t r y R e l a t i o n s h i p > < e n t r y R e l a t i o n s h i p t y p e = SUBJ > $ALRT_CONCERN $OINT_CONCERN $NO_ALLERGIES < / e n t r y R e l a t i o n s h i p > < / a c t > Fig. 4. Alerts: general structure of the clinical statements (Source: HL7 Italia) The detailed information for a generic alarm or an allergy or some intolerance, are listed as an Observation element. Further information, as for example the allergy status or the alert severity, can be included as specific classes referred through entryrelationship. Medications All the information related to prescriptions and substance administration are listed in the section named with LOINC 150

5 code (Medications). The general structure of the Medications section is reported in Figure 5. <component> < s e c t i o n > <templateid root = / > < t e m p l a t e I d r o o t = / > < t e m p l a t e I d r o o t = $ template_medication_section / > <id root= $ID_SEZ / > <code code= displayname = HISTORY OF MEDICATION USE codesystem= codesystemname= LOINC / > < t i t l e > T e r a p i e < / t i t l e > <text > $NARRATIVE_BLOCK < / t e x t > <! molteplicità 1..N Descrizione Terapia Farmacologica > < e n t r y > $MEDICATION $NO_MEDICATION < / e n t r y > < / s e c t i o n > < / component> Fig. 5. Medications: general structure of the section (Source: HL7 Italia) The information regarding a medication activity is represented through a substanceadministration derived from the template "Medication Activity". The general structure of the medication activity entry is reported in Figure 6. <substanceadministration classcode= SBADM moodcode= INT EVN > < t e m p l a t e I d r o o t = / > < t e m p l a t e I d r o o t = / > < t e m p l a t e I d r o o t = / > < t e m p l a t e I d r o o t = $ t e m p l a t e _ m e d i c a t i o n / > <id root= $ID_SEZ / > <text > < r e f e r e n c e v a l u e = #$REF_MED / > < / t e x t > < statuscode code= completed / > <! Obbligatorio indica i l periodo di inizio e fine della terapia > <! Se non noto deve e s s e r e v a l o r i z z a t o a UNK > <effectivetime xsi: type= IVL_TS > <low v a l u e = $LOW_TS n u l l F l a v o r ="UNK" / > <! OPZIONALE > < h igh v a l u e = $HIGH_TS n u l l F l a v o r ="UNK" / > < / e f f e c t i v e T i m e > <! OPZIONALE usato per indicare la posologia:e. g.2 volte i l giorno > < e f f e c t i v e T i m e o p e r a t o r = A x s i : t y p e = TS PIVL_TS EIVL_TS PIVL_PPD_TS SXPR_TS > $POSOLOGIA < / e f f e c t i v e T i m e > <! OPZIONALE > < routecode code = $COD_VIA_SOMM / > <! OPZIONALE > < d o s e Q u a n t i t y >$DOSE< / d o s e Q u a n t i t y > <! OPZIONALE > < a p p r o a c h S i t e C o d e code= $COD_APP_COD >< / a p p r o a c h S i t e C o d e > <! OPZIONALE > < r a t e Q u a n t i t y >$RATE< / r a t e Q u a n t i t y > <consumable > $FARMACO < / consumable > < / s u b s t a n c e A d m i n i s t r a t i o n > Fig. 6. Medications: general structure of the clinical statements (Source: HL7 Italia) Among the possible templates belonging to the medication family, in the Patient Summary now it is considered only the normal dosing. This template identifier is used to identify medication administration events that do not require any special processing. III. AN EXPERIENCE IN IMPLEMENTING THE CCM: GP/HS MEDICAL RECORDS Clinical information systems are one of the crucial factors in improving the continuity of care for chronic illnesses, such as diabetes, heart disease, hypertension and chronic obstructive pulmonary disease. Inside the clinical information systems, the clinical aspects summarized in the medical records need to be integrated among the General Practitioners and the Public Fields trxidentificazione trxanagrafica trxanamnesifamiliare trxesenzione trxintollfarmaco trxmalattiarilevante trxmonitoraggio trxprescrizione trxrisultato trxprescrizioneesstru trxprescrizionefarmaco trxprescrizionevisitaspecialistica trxricoveroospedaliero trxstilevita trxvaccinazione trxvisitammg trxxtradati Description Patient identification Patient registry Family History Patient exemption Alerts, adverse reaction Pathology, Chronic Disease Vital Signs Prescription (laboratory) Results Prescription (instrumental exams) Prescription (medications) Prescription (specialist visit) Hospitalization Social History Immunizations General Practitioner visit Specific application data TABLE II TRX-PDTA PRINCIPAL FIELDS AND DESCRIPTIONS Health organization. In order to implement the exchange and sharing of medical records between hospital and primary care for the management of the diagnostic and therapeutic paths (PDTA), is important to specify both the clinical data set and the technological interfaces and messaging, according also to the regional guidelines. Clinical data set Up to now, there are no national/regional standard specifications for the definition of the clinical data set in PDTA for the various chronic pathologies. Here, we consider the TRX-PDTA, a possible solution based on TRX-CICoM specifications. CICoM (Consorzio per la Interoperabilità e la Cooperazione Medica) [38] is an Interoperability and Medical Cooperation Consortium of GP software providers. TRX- PDTA is an XML dataset common to all PDTA, proposed within the Co.S. (Consorzio Sanità) [39], a GP Cooperative Consortium. This dataset is used in the horizontal integration among the different GP Medical Records systems in the implementation of diagnostic and therapeutic paths. In Table II the schema of the principal fields (tags) for the TRX-PDTA is reported. For each chronic illness, the TRX-PDTA needs to be further detailed and the various fields have to be specified. As a national example of guidelines for the management of chronic illness we report the IGEA Project Integrazione Gestione e Assistenza per la malattia diabetica, a chronic disease management project for people with diabetes. It contains recommendations for an integrated management of the type 2 diabetes mellitus in adults, addressing clinical and organizational requirements and information requirements with the definition of clinical and system indicators and a data dictionary [40]. Interface and messaging Both in the Hospital Specialist area and in the Primary Care area the integration allows the operators to use its own medical record systems in order to manage and archive the information related to the specific clinical dataset. As an example, the 151

6 diabetes medical record for the Hospital Specialist, and the personal Medical Record for the General Practitioner. The considered integration is based on a PDTA service (Progetto Sinapsis [41]) for the exchange and sharing of administrative and clinical data. The service operations comprise the clinical data sending, the query/response for the patient lists and the specialist visit lists, and the clinical data retrieving. To guarantee interoperability, the interactions of the PDTA services are based on HL7 messaging. As an example, in Figure 7 an HL7 v2.3 R01-unsolicited transmission of observation message (ORU) for diabetes is reported. MSH ^ ~ \ & EuroTouch MeTeDa S i n a p s i s DIAB ORU^R01 1 P 2. 3 PID 3 ^ ^ L^IDET~slvfnc29m05c552a ^^N^CODFISC~ ^^^CODSAN~ ^^^STP~^^^SGP _Cognome^ Esempio Bambino M PV1 1 I ORC XO 1 ^ ^ ^ D i a b e t o l o g i a 1 ^ ^ ^ D i a b e t o l o g i a OBR 1 1 R OBX 1 ST ES001^ G l i c e m i a a d i g i u n o OBX 2 ST ES003^ Emoglobina G l i c a t a OBX 3 ST PR018^ECG Normale OBX 4 ST CL057^Non R e t i n o p a t i a D i a b e t i c a OBX 5 ST CL058^ R e t i n o p a t i a D i a b e t i c a non P r o l i f e r a n t e OBX 6 ST CL059^ Retinopatia Diabetica non Proliferante l a s e r t r a t t a t a OBX 7 ST CL062^ R e t i n o p a t i a D i a b e t i c a P r o l i f e r a n t e OBX 8 ST CL065^ O f t a l m o p a t i a D i a b e t i c a Avanzata OBX 9 ST CL132^ U l c e r a OBX 10 ST CL133^Ulcera Pregressa ( assenza al momento della osservazione d i una l e s i o n e a t u t t o s p e s s o r e ) OBX 11 ST CL138^Ulcera In atto 0D lesione pre o postulcerativa completamente r i e p i t e l i z z a t a con i n f e z i o n e e i s c h e m i a OBX 12 ST CL141^Ulcera In atto IC lesione superficiale non c o i n v o l g e n t e t e n d i n i c a p s u l e e o s s a con i s c h e m i a OBX 13 ST CL145^Ulcera In atto IIC lesione interessante tendini o c a p s u l e con i s c h e m i a e1ef703cd06e ab692246b17a1e6d5ffe Fig. 7. HL7 v2.3 Observation (ORUˆR01) message for diabetes. (Source: Progetto Sinapsis PDTA) IV. CASE STUDY: HL7-BASED GP/HS INTEGRATION SERVICES Hereafter, we present a GP/HS integration project, which takes into account different integration aspects. In particular, it comprises the extension/integration of an existing project MITO.SI [42] Modulo Interconnessione Territorio Ospedale in provincia di Siena; Accordo ASL7 Siena / Coop Medici 2000 and the project proposal CSI-DIAB Cartella Specialistica Integrata - Diabete; AOU Careggi Firenze/ Medici di Medicina Generale ASL 10 Firenze [43]. The GP integration aspects related to the CDA Rel. 2 Prescription has been described in [44]. The project deals with the realization of integration services for General Practitioners (in Italian MMG, Medici di Medicina Generale and PLS, Pediatri di Libera Scelta ) and Hospital Specialists (in Italian SO Specialisti Ospedalieri) according to the technical specifications of e.toscana Compliance [45] and the infrastructure CART Cooperazione Applicativa della Regione Toscana [46], that enables the development of interoperable and cooperative software solutions, and the Carta Sanitaria Elettronica Tuscany Region Project [47]. A scheme with the various systems to be integrated is depicted in Figure 8. The main services offered are specified in details in the workpackage list shown in Table III. Workpackages WP1 WP2 WP3 WP4 WP5 WP6 WP7 WP8 WP9 WP10 WP11 Services Public Health Local Person/Patient Registry - HL7v3 Integration Public Health Code Systems - OID Integration Electronic Prescription Document - CDA Originator and Recipient Patient Summary/Medical Record - CDA Originator and Recipient Provide Patient Summary/Medical Record to EHR Retrieve Patient Summary/Medical Record from EHR Provide E-Prescription Document to SAR Retrieve E-Prescription Document from SAR GP/HS Medical Record HL7 Integration Security and Privacy - Carta sanitaria elettronica regionale Self Audit and Clinical Governance TABLE III WORKPACKAGES OF THE INTEGRATION SERVICES - GP/HS PROJECT The horizontal integration of the different Electronic Medical Record systems for General Practitioners has been taken into account by the MITO.SI project. We extend it, with a vertical integration to the EHR, both at local and regional public health organization level. Both the e-prescription and the Patient Summary are implemented according to the CDA Rel.2 standard. Collecting and comparing data for self-audits and clinical governance is also considered for General Practitioners, as required by the CCM. TRX-ANR is the XML dataset shared in the GP ANR (National Research Area), based on the TRX- CICoM specifications, used in the clinical audit process and for epidemiological studies on chronic diseases. Moreover, according to CCM, in order to develop the exchange of medical records between Hospital Specialists and General Practitioners, we consider a vertical integration through an interface (HL7-based) of the Clinical Information Systems, and an integration (CDA Rel. 2) with the EHR for the Hospital Specialists. The TRX-PDTA is the XML dataset common to all PDTA used for the exchange and the sharing of the medical record information. The interface to access the Person/Patient Registry is implemented according to the HL7v3-based regional specifications [48], [49]. We need also to implement the integration with the Public Health/Regional Code systems and Identification schema, according to the HL7 OIDs (Object Identifiers) [37]. The module Hospital Specialist (HS) Medical Record, depicted in Figure 8, is detailed with all its connections and HL7 interfaces in Figure 9. Notice that we are considering the main Chronic illness such as Diabetes, Heart disease, Hypertension, Chronic Obstructive Pulmonary disease and Brain stroke. In Figure 10 the scheme of the Person/Patient Registry HL7v3 Integration is drawn. It refers to WP1 and WP2 workpackages. As shown, an integration is needed between the person/patient registry of the GP/HS Medical Record systems and the Public Health person/patient registry. This integration is implemented through two services: an HL7 patient registry interface using the regional Common Terminology (OID); a 152

7 Fig. 8. Integration Schema - GP/HS Project In Figure 11 the integration scheme of the CDA Rel.2 Patient Summary is shown, referring to WP4,WP5,WP6 and WP2 workpackages. This scheme shows how the various services interact to provide (and retrieve) Patient Summary documents to (from) the EHR, at regional and local level. Fig. 9. HS Medical Record (Expanded Chronic Care model): Details on connections and interfaces consumer of the Public Health person/patient registry service through the Local Application Node to the CART infrastructure. Fig. 11. CDA Rel.2 Patient Summary - GP/HS Project V. F INAL R EMARKS Fig. 10. The proposed GP/HS project represents, at regional level, an example of integration/interoperability for the Patient Summary documents, the Prescription documents and the PDTA medical records within the Electronic Health Record. This in line with the Italian IPSE [50] and European epsos (European Patients Smart Open Services [51]) projects, with their initial focus on both patient summary/emergency data sets and medication record/eprescribing solutions. Tuscany Region and various other Italian regions are involved in the [50] project; and Italy with Lombardia Region and many European member Person/Patient Registry HL7v3 Integration - GP/HS Project 153

8 states are involved in [51]. The analysis carried out in these projects pointed out that the European situation is diversified with some regions and countries more advanced than others in terms of their capacity to implement EHR solutions. In Italy, the situation from region to region is also very dissimilar. It also highlights that interoperability among different systems is the key to enhance the possibility of these services being provided across national or regional borders. Future developments of the diagnostic and therapeutic paths (PDTA) need a standardization of the clinical data set with a strong interaction among Hospital Specialists and General Practitioners with the participation of the scientific and medical society for the different specialties related to the various chronic diseases. It is also needed a standard definition of the PDTA document structure according to CDA Rel.2 to ensure interoperability within the EHR, in consideration also of the TSE activity [10]. An ongoing HL7 international project on definition of minimum data set and data standards in EHR systems for diabetes assessment in outpatient clinic settings is documented in [52]. The development and localization of the Patient Summary has been started with the involvement of the GP. The work of the HL7 Italia Group [25] is actually in progress and TSE has recently released a draft of technical specifications for the creation of the Profilo Sanitario Sintetico according to the standard CDA Rel.2 [53]. ACKNOWLEDGMENT The authors would like to thank HL7 Italia and the colleagues of the Gruppo di Progetto HL7 Italia IG CDA2 Profilo Sanitario Sintetico for the localization activity, here partially reported. REFERENCES [1] Rapporto 2008 Osservatorio ICT & CIO in Sanità MIP Politecnico di Milano, Maggio [2] Rapporto 2010 Osservatorio ICT in Sanità MIP Politecnico di Milano, Maggio [3] ICIC Improving Chronic Illness Care. [4] HL7v3 Standard, Health Level Seven International, [5] Piano Sanitario Regionale Consiglio Regionale della Toscana, Deliberazione n.53 del 16 luglio [6] Le aziende sanitarie verso il fascicolo sanitario elettronico: stato del arte e prospettive. Florence, January 15, 2010, [7] Piano di e-government Obiettivo 4: Salute [8] TSE - IBSE: Strategia architetturale per la Sanità Elettronica, v01.00, 31/03/2006: view_file.php?curent_file=361&curent_dir=39 [9] InFSE: Infrastruttura tecnologica del Fascicolo Sanitario Elettronico - Linee guida e specifiche tecniche. Data: 15/06/2010, Versione: v linee guida e specifiche tecniche_v1.0.pdf [10] TSE - Tavolo di lavoro permanente per la Sanità Elettronica delle Regioni e delle Provincie Autonome. Specifiche tecniche per la creazione del Documento di Referto secondo lo standard HL7-CDA Rel. 2 Versione 1.1, 27/01/ [11] HL7 Clinical Document Architecture Release 2.0, Normative Edition, May 2005, ANSI/HL7 CDA,R /21/2005, ISO/HL :2008. [12] Ministero del Lavoro, della Salute, e delle Politiche Sociali, Mattone 09, Realizzazione del Patient File, Principi generali sul Fascicolo Sanitario Personale, 11 Luglio 2007: paginainternamenumattoni.jsp?id=12&menu=mattoni [13] IT Infrastructure Technical Framework [14] TSE Una Politica per la Sanità Elettronica, 31/03/ Politica Condivisa per la Sanità Elettronica.pdf [15] HL7 Implementation Guide:CDA Release 2, Continuity of Care Document (CCD) A CDA implementation of ASTM E Standard Specification for Continuity of Care Record (CCR), April 01, [16] IHE Patient Care Coordination (PCC) Technical Framework,Revision 5.0, [17] HL7 Implementation Guide for CDA Release 2: History and Physical (H&P) Notes (US Realm), DSTU, August [18] HITSP Summary Documents Using HL7 Continuity of Care (CCD) Component HITSP/C32, Version 2.5 July 8, [19] HITSP CDA Content Modules Component HITSP/C83, Version 1.1 July 8, [20] HL7 Implementation Guide for CDA Release 2, Level 1 and 2, Care Record Summary (US Realm) Final Text, June 23, [21] Carta Regionale dei Servizi SISS Secondo Stadio Specifiche di Struttura CDA2, Patient Summary Regione Lombardia, Versione 2.0, 15/05/2009. [22] LUMIR, Lucania Medici in Rete Patient Summary e documentazione clinica Regione Basilicata, Versione [23] Rete di Medici di Medicina Generale, Progetto esecutivo definitivo Specifiche tecniche per la produzione del Patient Summary in formato HL7 Versione 3 CDA Rel.2 Regione Abruzzo. [24] RFC 133 Carta Sanitaria Regione Toscana. Patient Summary (Profilo Sanitario Sintetico), Versione 1.01 del [25] HL7 Italia Implementation Guide Clinical Document Architecture (CDA) Rel. 2, Profilo Sanitario Sintetico (Patient Summary), (IT Realm), standard informativo, Bozza (WIP), 02 marzo [26] Delibera n. 894 del PSR : Progetto Dalla medicina di attesa alla sanità d iniziativa. Approvazione indirizzi per attuazione della sanità di iniziativa a livello territoriale e per la gestione dei percorsi territorio - ospedale - territorio. [27] Delibera n.716 del PSR , punto Progetto per attuazione della sanità d iniziativa a livello territoriale. [28] Delibera n. 467 del Approvazione schema di Accordo tra Regione Toscana e organizzazioni sindacali rappresentative della Medicina Generale sul ruolo della Medicina Generale nella attuazione del PSR [29] Parere n. 1/2009 Percorsi territorio - ospedale - territorio. Programma di formazione e informazione sensibilizzazione su sanità di iniziativa e gestione delle malattie croniche. Chronic Care Model: Ruolo e competenze dei diversi attori. [30] Parere n. 52/2008 Percorsi Territorio - Ospedale - Territorio: percorsi assistenziali. [31] Parere n. 37/2008 Percorsi Territorio - Ospedale - Territorio: trasmissione parere. [32] T. Bodenheimer, E.H. Wagner, K. Grumbach, Improving primary care for patients with chronic illness, JAMA 2002; 288: [33] World Health Organization, Innovative care for chronic conditions, Building blocks for action, 2002, Geneva. [34] U.J. Barr, S. Robinson, B. Marin Link, L. Underh ill, The Expanded Chronic Care Model, Hospital Quarterly, Vol.7, No 1, 73,82, [35] J. De Maeseneer et al., Primary health care as a strategy for achieving equitable care, a literature review commissioned by Health Systems Knowledge Network, WHO, March [36] HL7 Italia CDA Working Group, Clinical Document Architecture (CDA) Rel.2, Sezione Header, Guida Implementativa di Localizzazione Italiana, Versione 1.0, Settembre 2008: [37] HL7 Italia Identificazione Object Identifiers (OID), Versione 2.0, 26 maggio 2009: [38] C.I.Co.M. Consorzio per Interoperabilitá e la Cooperazione Medica. op=modload&name=altro&file=index&req=contatti [39] Co.S Consorzio di Consorzi regionali di Cooperative di medici di famiglia. [40] Progetto IGEA - Requisiti Informativi per un sistema di gestione integrata del diabete mellito di tipo 2 nell adulto: documento di indizzo [41] SINAPSIS (Suite INterconnesione Avanzata Per Sistemi Informativi Sanitari) 154

9 [42] Progetto MITO.SI Moduli di Interconnessione Territorio Ospedale in Provincia di Siena: _15_Pozzi_Visconti.ppt [43] Progetto CSI DIAB ehealthtech Internal Technical Report, March 2010, Decreto RT n.26 del 12 gennaio 2010 Aiuti allo sviluppo sperimentale. [44] R. Calamai and L. Giarré. HL7v3 CDA Rel.2 Prescription: Localization Experience and GP Integration Project. IEEE Workshop on Health Care Management, Venice, February [45] e.toscana compliance: loadstaticpage?staticpage=index.html [46] CART: [47] Delibera n.125 della Giunta regionale della Toscana del 23 febbraio 2009, PSR 2008/2010, punto Approvazione progetto Carta Sanitaria Elettronica [48] e.toscana compliance RFC85.4 Servizi Anagrafe Persone HL7v3 (Standard ). [49] e.toscana compliance RFC86.4 Servizi Generale Anagrafe Sanitaria HL7v3 (Standard ). [50] IPSE: Sistema per la Interoperabilità nazionale delle soluzioni di Fascicolo Sanitario Elettronico: Patient Summary e eprescription. [51] epsos Project (European Patients Smart Open Services). [52] EHR Diabetes Data Strategy Diabetes Data Strategy [53] TSE - Tavolo di lavoro permanente per la Sanità Elettronica delle Regioni e delle Provincie Autonome. Specifiche tecniche per la creazione del Profilo Sanitario Sintetico secondo lo standrad HL7-CDA Rel. 2, 21/06/2010, Bozza tecniche del profilo sanitario sintetico in formato hl7 cda v.2 (bozza).pdf 155