HL7v3 CDA Rel.2 Patient Summary and ChronicCare Model: Localization Experience and GP/HS

Integration ProjectRenato Calamai

eHealthTechVia delle Cantine 27 50041 Calenzano (FI) - Italy

Email: renato.calamai@ehealthtech.it

Laura GiarréDias-Università di Palermo

Viale delle Scienze 90128 Palermo - ItalyEmail: giarre@unipa.it

Abstract—The localization experience for the Patient Sum-mary, based on the Health Level Seven Version 3 (HL7v3) ClinicalDocument Architecture, Release 2 (CDA Rel.2), is presented.An overview of the Chronic Care Model (CCM) is introducedwith particular attention to the clinical information systems,in order to organize patient and population clinical data bysharing information among healthcare providers in managementof chronic diseases. We propose, as case study, a project for theintegration of various services for General Practitioners (GP) andHospital Specialists (HS), accessing the Electronic Health Record(EHR), implementing the Patient Summary and managing theexchange of Chronic Care medical records. This project is inline with the state of the art in the normative referring contextfor the Italian healthcare, both at national and regional level(Tuscany Region).

Index Terms—e-Health, HL7, Interoperability, Chronic CareModel, Patient Summary, EHR

I. INTRODUCTION

New challenges in healthcare should be based [1], [2] ona rationalization of administrative and managerial processes;an improvement of the clinical and healthcare processes; areduction of clinical risks; and an expanded Chronic CareModel (CCM) [3] in order to overcome the deficiencies incurrent management of chronic disease. The Italian healthcaresituation is characterized by an huge diffusion of hetero-geneous ad hoc applications and legacy systems in all theadministrative and clinical domains; a very low presence ofadvanced solutions (Service Oriented Architecture and Busi-ness Process Management); deficiency of guidelines both atregional and national level; and, finally, lack of applicationsbased on technological standards. One of the solution is theuse of innovative standards for the integration of the informa-tion systems and the implementation of application solutionsbased on modern technological standards. The use of standardenables the interoperability. Interoperability is the ability oftwo or more systems or components to exchange informationand to use the information that has been exchanged. We willrefer to HL7v3 [4] as the most widely used standard for health-care interoperability. The Patient Summary (in Italian ProfiloSanitario Sintetico (PSS)), an electronic clinical documentsummarizing the most relevant clinical information facts about

a patient’s healthcare, represents one of the main elements ofthe Electronic Health Record (EHR) systems.

The integration of the Clinical Information Systems, be-tween hospital and primary care is one of the essential aspectsof the Chronic Care Model, as reported in [5] for TuscanyRegion, for the development of diagnostic and therapeuticpaths Percorsi Diagnostico Terapeutici Assistenziali (PDTA).

In a recent FIASO (Federazione Italiana Aziende Sanitariee Ospedaliere) report [6] an optimistic picture of the Italiansituation is overviewed with regards to the knowledge of theEHR (71% of GPs and 67% of HSs) and a spread use of EHRand Patient Summary reported as 7 regions among 20.

The paper is organized as follows: in the following wepresent the referring normative and technological context witha brief overview of the standard HL7v3 for the Clinical Docu-ment Architecture (CDA) Rel.2, and the Chronic Care Modelfor the Clinical Information Systems; in section II we describethe experience with the CDA Rel.2 localization for PatientSummary and in section III the experience in implementingthe CCM medical record; in section IV we describe a projectof Integration for General Practitioners (GP) and HospitalSpecialists (HS), accessing the EHR, implementing the PatientSummary and managing the exchange of Chronic Care medicalrecords; 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 de-scribed in the project of the Health objective for the Italianplan e-Gov 2012 [7], including the project Medici in Retefor the connection of the General Practitioners and the Pe-diatricians with the regional infrastructures; and the projectFascicolo Sanitario Elettronico (FSE) for the implementationof a distributed solution for patient’s EHR (in Italian FSE),at regional, national and European level. The technologicalreferences have been published by the Tavolo permanente diSanità Elettronica (TSE) composed by the regional represen-tatives, and coordinated by the Department Digitalizzazione eInnovazione Tecnologica of the Innovation and Public Admin-istration Ministry (Ministero della Pubblica Amministrazionee Innovazione), with the participation of the Health Ministry

978-1-4244-6587-3/10/$25.00 É2010 IEEE

147

(Ministero della Salute) and DigitPA. These documents arerelated to architectural strategies for e-health; the regional EHRguidelines [8]; the definition of the national EHR technologicalinfrastructure (InFSE) [9]; and the technical specifications ofthe 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 MattoniSSN (Servizio Sanitario Nazionale) Realizzazione del PatientFile [12], HL7 Version 3 has been indicated as the messagingstandard in healthcare information exchange, and HL7-CDARel. 2 as the standard for clinical documents exchange. TheIHE-XDS profile (Cross-Enterprise Document Sharing) is alsosuggested as one of the reference framework for registering andsharing electronic health record documents between healthcareenterprises [13].

In the present work, we mainly focus on the Patient Sum-mary that is an important aspect in the GP systems integrationwith the EHR. In the past, TSE started various regional projectsfor the General Practitioners [14] Sanità Elettronica - Rete deiMedici di Medicina Generale, including the Patient Summary,the electronic clinical document summarizing the most rele-vant clinical information facts about a patient’s healthcare, tosupport the continuity of care. Patient Summary is a documentof the EHR that must be created, updated and digital signed bythe GPs providing a snapshot in time containing the pertinentclinical data, as the emergency data set. Patient Summaryis developed according to the standard CDA Rel. 2 and isbased on the HL7 Continuity Care Document (CCD), a CDAimplementation 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 fa-cilitate the sharing of information between the various actorsinvolved in the process of care and assistance of a patienthas been recently increased at international level (see Belgium(SUMEHR), England (Summary Health Record), Sweden,Finland (Patient Core Data Set), U.S. (Continuity of CareRecord), Canada). In Italy, up to now, the standard for thePatient Summary CDA Rel.2 has not been yet delivered. TheTSE is working on a draft document for the definition of thePatient Summary, based on the indications resulting from thevarious regional projects Medici in Rete, among which theCR SISS Regione Lombardia [21] LUMIR Regione Basilicata[22], RMMG Regione Abruzzo [23]. In Tuscany Region, PatientSummary is defined in the RFC 133 [24], according to [25].

The exchange and sharing of clinical information in chronicillness is an other important aspect of the GP IntegrationProject with the Hospital Specialist. The integration of theClinical Information Systems, with particular attention to theGP Medical Records with the Hospital Specialist MedicalRecords represents one of the essential elements in implement-ing the Chronic Care Model (CCM). This aspect is in line withthe development of a proactive healthcare that is based onan integrated management of the diagnostic and therapeuticpaths (PDTA) between hospitals and primary care with the

community-based facilities and services. The normative refer-ring context at Tuscany Region level is the Piano SanitarioRegionale (PSR) 2008-2010 [5], specifically the objectives ofproactive healthcare and the Chronic Care Model; the variousbylaws of Regional Health Department [26], [27],[28]; and theopinions of the Regional Council Health Committee [29], [30],[31].

B. HL7 Version 3 CDA Rel.2

Health Level Seven International (HL7) is the leadingglobal authority for healthcare information interoperability andstandards with members in over 55 countries. HL7 is "an ANSIaccreditated standard development organization dedicated toproviding a comprehensive framework and related standardsfor the exchange, integration, sharing, and retrieval of elec-tronic health information that supports clinical practice andthe management, delivery and evaluation of health services"[4]. HL7 Version 3 (HL7v3) is a reference paradigm for thesyntactic-semantic interoperability. The HL7 V3 methodologyuses the Reference Information Model (RIM), the Data TypesSpecification, and the HL7 Vocabulary as its starting point. Itthen establishes a message development process for refiningand constrain the Reference Information Model to arrive atthe Hierarchical Message Descriptor (HMD) that specifies anumber of messages called Message Types.

The following Figure 1 shows the refinement process spec-ified in the methodology. As diagrammed, the processes areused to derive one or more Domain Message InformationModels (D-MIM) from the RIM. Each such model representsthe set of concepts embodied in the individual Refined Mes-sage Information Model (R-MIM) needed to represents therequirements 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) isa document markup standard that specifies the struc-ture and semantics of clinical documents for the pur-pose of exchange. CDA documents are encoded in Ex-tensible Markup Language (XML). A CDA document iswrapped by the <ClinicalDocument> element, and con-tains a header and a body . The header lies between the<ClinicalDocument> and the <structuredBody> el-ements, and identifies and classifies the document and providesinformation on authentication, the encounter, the patient, and

148

the involved providers. The body contains the clinical report,and can be either an unstructured blob, or can be comprisedof structured markup. A CDA document section is wrappedby the <section> element. Each section can contain asingle narrative block , and any number of CDA entries andexternal references. The CDA narrative block is wrapped bythe <text> element within the <section> element, andmust contain the human readable content to be rendered.

C. Chronic Care ModelThe Chronic Care Model summarizes the basic elements

for improving chronic illness care in health systems at thecommunity, organization, practice and patient levels. Thismodel, elaborated by Prof. Wagner of the Mac-Coll Institutefor Healthcare Innovation [3], [32], identifies the essentialelements of a health care system that help high-quality chronicdisease 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 systemsIn 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 Journalsand Books)

of this model are productive interactions between an informedand activated patient and a prepared and proactive multi-professional health care team. Informed patients have sufficientinformation to become a wise decision-maker related to theirillness and they also need to be activated by understanding theimportance of their role in managing the illness. A preparedteam is a practice team that is organized, trained, and equippedto conduct productive interaction. A productive interaction isone that assures that patient needs for evidence-based clinicaland behavioral care information and support to become betterself-managers, and monitoring over time are met, as reportedin [3].

Clinical information systems are the crucial factor in im-proving chronic illness care with their clinical database con-taining 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 theirchronic illness for proactive care; facilitating individual patientcare planning; sharing information with providers and patients;and, finally, monitoring performance of team with respect tothe chronic care illness indicators.

The Chronic Care Model will require a transformationof health care, from a system that is essentially reactive -responding mainly when a person is sick - to one that isproactive and focused on keeping a person as healthy aspossible. This model has been promoted by the World HealthOrganization [33] and exploited in many countries such asCanada, Holland, Germany, United Kingdom, Denmark. InTuscany Region this model has been used as the basis forthe Expanded Chronic Care Model [34],[35] where the singlepatient takes a more informed role inside the community andwhere the General Practitioner clinical aspects are integratedwith those of the public health.

II. AN EXPERIENCE IN LOCALIZING THE CDA REL.2 FORPATIENT SUMMARY

Localization is the process of defining new HL7 Version 3Message Types by a process that includes both the constraintprocess and an extension process that adds new concepts tothe base Message Type. Any local HL7 affiliated organizationneeds to adapt the standard to the national or regional require-ments. We report hereafter a brief summary of the experienceof localization carried out with HL7 Italia, in the V3 DomainWorking Group - Gruppo di Progetto HL7 Italia IG CDA2Profilo Sanitario Sintetico. Within this experience, the docu-ment Implementation Guide Clinical Document Architecture(CDA) Rel. 2 Profilo Sanitario Sintetico (IT Real) is actuallyunder discussion [25],[15],[16], [36].

Through the Patient Summary, the GP supplies a patientoverview with a synthesis containing the only relevant dataand let it available to the EHR. The principal aims of the PSSwill then be the following: let the information be availablefor the emergency; help the chronic care processes; ensure thecontinuity of care. The PSS is a document satisfying somerequirements:

- it must be synthetic and contain only the essential infor-mation;

- it must have a single author, the General Practitioners/-Pediatricians creating and updating it;

- it is not clinically specialized to be used in differentscenarios (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 fordocument, section, clinical statement and entry levels. More-over the header must be compliant with the CDA Rel. 2 Headeras defined by HL7 specifications and localized by HL7 Italia

149

CCD Section RequirementsPurpose SHALL NOTPayers SHALL NOT

Medical Equipment RECOMMENDEDImmunization OPTIONAL

Vital Signs OPTIONALResults RECOMMENDED

Procedures OPTIONALEncounters OPTIONAL

Plan of Care OPTIONALAdvance Directives SHALL NOTFunctional Status OPTIONAL

Problems REQUIREDFamily History OPTIONALSocial History OPTIONAL

Alerts REQUIREDMedications REQUIRED

History of Pregnancies OPTIONAL

TABLE ILIST OF REQUIREMENTS FOR THE INCLUSION OF THE CCD SECTIONS

(SOURCE: HL7 ITALIA)

[36]. Patient Summary also follows the coding specificationdefined in the HL7 Italia document Identificazione ObjectIdentifiers (OID) [37].

Patient Summary has been defined according to the CDAR-MIM. It is structured in a Header and a CDA Body, humanreadable (level 2) and machine readable (level 3).

The CDA Body, structured in specific sections, contains thepatient clinical data. The various elements <section> in thebody 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 entrywill always be reported also as text in the narrative block.Not all the CCD sections have been implemented in the CDABody. Table I reports which section is required, optional or notrequired, up to now.

We report the CCD sections that are now under discussionin the Patient Summary localization.

• Alerts: section collecting alarms relative to any allergies,adverse reactions, and alerts that are pertinent to thepatient’s current or past medical history.

• Medications: section collecting all the actual prescribedpharmacological therapies. At a minimum, the currentlyactive medications should be listed, with an entire medica-tion history as an option, particularly when the summarydocument is used for comprehensive data export.

• Immunizations: section defining a patient’s current im-munization status and pertinent immunization history.The section should include current immunization status,and may contain the entire immunization history that isrelevant to the period of time being summarized.

• Problems: section deputed to summarize the relevantclinical problems, including the main pathologies. At aminimum, all pertinent current and historical problemsshould be listed. CDA Rel.2 represents problems asObservations.

• Family History: section collecting the family medicalhistory, relevant for the patient risks. This section contains

data defining the patient’s genetic relatives that have apotential impact on the patient’s healthcare risk profile.

• Social History: section containing the patient’s occupa-tional, personal (e.g. lifestyle), social and environmentalhistory. Social history can have significant influence ona patient’s physical, psychological and emotional healthand wellbeing.

In the following, the CDA body for Alerts and Medicationssections are reported as an example of localization.

Alerts

The information related to allergies and pharmacologicalreaction are listed in the section named with the LOINCcode 48765-2 (Allergies, adverse reactions, alerts). The generalstructure of the Alerts section is reported in Figure 3.

<component>< s e c t i o n >

< t e m p l a t e I d r o o t = ’ 2 . 1 6 . 8 4 0 . 1 . 1 1 3 8 8 3 . 1 0 . 2 0 . 1 . 2 ’ / >< t e m p l a t e I d r o o t = ’ 1 . 3 . 6 . 1 . 4 . 1 . 1 9 3 7 6 . 1 . 5 . 3 . 1 . 3 . 1 3 ’ / >< t e m p l a t e I d r o o t = ’ 2 . 1 6 . 8 4 0 . 1 . 1 1 3 8 8 3 . 2 . 9 . 1 0 . 1 . 4 . 2 . 1 ’ / >< i d r o o t = ’ $ID_SEZ ’ / ><code code= ’48765−2 ’ d isp layName = ’ A l l e r g i e , R e a z i o n i Avverse , A l l a r m i ’

codeSystem= ’ 2 . 1 6 . 8 4 0 . 1 . 1 1 3 8 8 3 . 6 . 1 ’ 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 >< t e x t >

$NARRATIVE_BLOCK< / t e x t >< !−− M o l t e p l i c i t à 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 throughan act derived from the template "Allergy and IntoleranceConcern". The general structure of the entry Alarm is reportedin 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 = ’ 2 . 1 6 . 8 4 0 . 1 . 1 1 3 8 8 3 . 1 0 . 2 0 . 1 . 2 7 ’ / >< t e m p l a t e I d r o o t = ’ 1 . 3 . 6 . 1 . 4 . 1 . 1 9 3 7 6 . 1 . 5 . 3 . 1 . 4 . 5 . 1 ’ / >< t e m p l a t e I d r o o t = ’ 1 . 3 . 6 . 1 . 4 . 1 . 1 9 3 7 6 . 1 . 5 . 3 . 1 . 4 . 5 . 3 ’ / >< !−− s p e c i f i c a r e s t r i z i o n i a g g i u n t i v e s p e c i f i c h e d i q u e s t a gu ida −−>< t e m p l a t e I d r o o t = ’ 2 . 1 6 . 8 4 0 . 1 . 1 1 3 8 8 3 . 2 . 9 . 1 0 . 1 . 4 . 3 . 1 ’ / >< i d r o o t = ’ $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 −−>< h igh 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 allergyor some intolerance, are listed as an Observation element.

Further information, as for example the allergy status orthe alert severity, can be included as specific classes referredthrough entryRelationship.

Medications

All the information related to prescriptions and substanceadministration are listed in the section named with LOINC

150

code 10160-0 (Medications). The general structure of theMedications section is reported in Figure 5.

<component>< s e c t i o n >

< t e m p l a t e I d r o o t = ’ 2 . 1 6 . 8 4 0 . 1 . 1 1 3 8 8 3 . 1 0 . 2 0 . 1 . 8 ’ / >< t e m p l a t e I d r o o t = ’ 1 . 3 . 6 . 1 . 4 . 1 . 1 9 3 7 6 . 1 . 5 . 3 . 1 . 3 . 1 9 ’ / >< t e m p l a t e I d r o o t = ’ 2 . 1 6 . 8 4 0 . 1 . 1 1 3 8 8 3 . 2 . 9 . 1 0 . 1 . 4 .

$ t e m p l a t e _ m e d i c a t i o n _ s e c t i o n ’ / >< i d r o o t = ’ $ID_SEZ ’ / ><code code= ’10160−0 ’ d isp layName = ’HISTORY OF MEDICATION USE ’

codeSystem= ’ 2 . 1 6 . 8 4 0 . 1 . 1 1 3 8 8 3 . 6 . 1 ’ codeSystemName= ’LOINC ’ / >< t i t l e > T e r a p i e < / t i t l e >< t e x t >

$NARRATIVE_BLOCK< / t e x t >< !−− m o l t e p l i c i t à 1 . . N − D e s c r i z i o n e T e r a p i a Farmaco log ica −−>< 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 rep-resented through a substanceAdministration derivedfrom the template "Medication Activity". The general structureof the medication activity entry is reported in Figure 6.

< s u b s t a n c e A d m i n i s t r a t i o n c l a s s C o d e = ’SBADM’ moodCode= ’ INT | EVN’>< t e m p l a t e I d r o o t = ’ 2 . 1 6 . 8 4 0 . 1 . 1 1 3 8 8 3 . 1 0 . 2 0 . 1 . 2 4 ’ / >< t e m p l a t e I d r o o t = ’ 1 . 3 . 6 . 1 . 4 . 1 . 1 9 3 7 6 . 1 . 5 . 3 . 1 . 4 . 7 ’ / >< t e m p l a t e I d r o o t = ’ 1 . 3 . 6 . 1 . 4 . 1 . 1 9 3 7 6 . 1 . 5 . 3 . 1 . 4 . 7 . 1 ’ / >< t e m p l a t e I d r o o t = ’ 2 . 1 6 . 8 4 0 . 1 . 1 1 3 8 8 3 . 2 . 9 . 1 0 . 1 . 4 . $ t e m p l a t e _ m e d i c a t i o n ’ / >< i d r o o t = ’ $ID_SEZ ’ / >< t e x t >

< r e f e r e n c e v a l u e = ’ #$REF_MED ’ / >< / t e x t >< s t a t u s C o d e code= ’ comple t ed ’ / >< !−− O b b l i g a t o r i o i n d i c a i l p e r i o d o d i i n i z i o e f i n e d e l l a t e r a p i a −−>< !−− Se non no to deve e s s e r e v a l o r i z z a t o a UNK−−>< e f f e c t i v e T i m e x s i : t y p e = ’ 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 u s a t o per i n d i c a r e l a p o s o l o g i a : e . g . 2 v o l t e i l g i o r n o−−>< 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 −−>< rou teCode 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: HL7Italia)

Among the possible templates belonging to the medicationfamily, in the Patient Summary now it is considered only thenormal dosing. This template identifier is used to identify med-ication administration events that do not require any specialprocessing.

III. AN EXPERIENCE IN IMPLEMENTING THE CCM: GP/HSMEDICAL RECORDS

Clinical information systems are one of the crucial factorsin improving the continuity of care for chronic illnesses, suchas diabetes, heart disease, hypertension and chronic obstructivepulmonary disease. Inside the clinical information systems, theclinical aspects summarized in the medical records need tobe integrated among the General Practitioners and the Public

Fields DescriptiontrxIdentificazione Patient identification

trxAnagrafica Patient registrytrxAnamnesiFamiliare Family History

trxEsenzione Patient exemptiontrxIntollFarmaco Alerts, adverse reaction

trxMalattiaRilevante Pathology, Chronic DiseasetrxMonitoraggio Vital SignstrxPrescrizione Prescription (laboratory)

trxRisultato ResultstrxPrescrizioneEsStru Prescription (instrumental exams)

trxPrescrizioneFarmaco Prescription (medications)trxPrescrizioneVisitaSpecialistica Prescription (specialist visit)

trxRicoveroOspedaliero HospitalizationtrxStileVita Social History

trxVaccinazione ImmunizationstrxVisitaMMG General Practitioner visit

trxXtraDati Specific application data

TABLE IITRX-PDTA PRINCIPAL FIELDS AND DESCRIPTIONS

Health organization. In order to implement the exchange andsharing of medical records between hospital and primary carefor the management of the diagnostic and therapeutic paths(PDTA), is important to specify both the clinical data set andthe technological interfaces and messaging, according also tothe regional guidelines.

Clinical data set

Up to now, there are no national/regional standard speci-fications for the definition of the clinical data set in PDTAfor the various chronic pathologies. Here, we consider theTRX-PDTA, a possible solution based on TRX-CICoM spec-ifications. CICoM (Consorzio per la Interoperabilità e laCooperazione Medica) [38] is an Interoperability and MedicalCooperation Consortium of GP software providers. TRX-PDTA is an XML dataset common to all PDTA, proposedwithin the Co.S. (Consorzio Sanità) [39], a GP CooperativeConsortium. This dataset is used in the horizontal integrationamong the different GP Medical Records systems in theimplementation of diagnostic and therapeutic paths. In TableII the schema of the principal fields (tags) for the TRX-PDTAis reported. For each chronic illness, the TRX-PDTA needs tobe further detailed and the various fields have to be specified.

As a national example of guidelines for the managementof chronic illness we report the IGEA Project IntegrazioneGestione e Assistenza per la malattia diabetica, a chronicdisease management project for people with diabetes. It con-tains recommendations for an integrated management of thetype 2 diabetes mellitus in adults, addressing clinical andorganizational requirements and information requirements withthe definition of clinical and system indicators and a datadictionary [40].

Interface and messaging

Both in the Hospital Specialist area and in the Primary Carearea the integration allows the operators to use its own medicalrecord systems in order to manage and archive the informationrelated to the specific clinical dataset. As an example, the

151

diabetes medical record for the Hospital Specialist, and thepersonal Medical Record for the General Practitioner. Theconsidered integration is based on a PDTA service (ProgettoSinapsis [41]) for the exchange and sharing of administrativeand clinical data. The service operations comprise the clinicaldata sending, the query/response for the patient lists and thespecialist visit lists, and the clinical data retrieving. To guar-antee interoperability, the interactions of the PDTA servicesare based on HL7 messaging. As an example, in Figure 7 anHL7 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 | 2 0 0 9 0 5 1 3 0 5 3 5 3 3 | |ORU^R01 | 1 | P | 2 . 3 | | | | | | | |PID | | | 3 ^ ^ L^IDET~ s lv fnc29m05c552a ^^N^CODFISC~11111111111111111111^^^CODSAN~^^^STP~^^^SGP | | _Cognome^ Esempio Bambino | | 1 9 8 6 0 2 1 1 1 2 0 0 0 0 |M | | | | | | | | | | | | | | | | | |PV1 | 1 | I | | | 1 | | | | | | | | | | | | | | 1 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1 | |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 | | 2 0 0 9 0 6 1 2 1 2 0 0 0 0 | 2 0 0 9 0 6 1 2 1 3 0 0 0 0 | | | | | | | | | | | | | | | | | | | | | | | | | | | |OBX | 1 | ST | ES001^ G l i c e m i a a d i g i u n o | | 1 0 0 | | | | | | | | | 2 0 0 9 0 5 1 3 1 2 0 0 0 0 | | |OBX | 2 | ST | ES003^ Emoglobina G l i c a t a | | 1 0 0 | | | | | | | | | 2 0 0 9 0 5 1 3 1 2 0 0 0 0 | | |OBX | 3 | ST | PR018^ECG | | Normale | | | | | | | | | 2 0 0 9 0 5 1 3 1 2 0 0 0 0 | | |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 | | | | | | | | | | | 2 0 0 9 0 5 1 3 1 2 0 0 0 0 | | |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 | | | | | | | | | | |2 0 0 9 0 5 1 3 1 2 0 0 0 0 | | |OBX | 6 | ST | CL059^ 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 −l a s e r t r a t t a t a | | | | | | | | | | | 2 0 0 9 0 5 1 3 1 2 0 0 0 0 | | |

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 | | | | | | | | | | | 2 0 0 9 0 5 1 3 1 2 0 0 0 0 | | |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 Avanza ta | | | | | | | | | | | 2 0 0 9 0 5 1 3 1 2 0 0 0 0 | | |OBX | 9 | ST | CL132^ U l c e r a | | | | | | | | | | | 2 0 0 9 0 5 1 3 1 2 0 0 0 0 | | |OBX| 1 0 | ST | CL133^ U l c e r a − P r e g r e s s a ( a s s e n z a a l momento d e l l a o s s e r v a z i o n ed i una l e s i o n e a t u t t o s p e s s o r e ) | | | | | | | | | | | 2 0 0 9 0 5 1 3 1 2 0 0 0 0 | | |OBX| 1 1 | ST | CL138^ U l c e r a − In a t t o − 0D l e s i o n e pre− o p o s t u l c e r a t i v acomple t amen te r i e p i t e l i z z a t a con i n f e z i o n e ei s c h e m i a | | | | | | | | | | | 2 0 0 9 0 5 1 3 1 2 0 0 0 0 | | |OBX| 1 2 | ST | CL141^ U l c e r a − In a t t o − IC l e s i o n e s u p e r f i c i a l enon 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 coni s c h e m i a | | | | | | | | | | | 2 0 0 9 0 5 1 3 1 2 0 0 0 0 | | |OBX| 1 3 | ST | CL145^ U l c e r a − In a t t o − I IC l e s i o n e i n t e r e s s a n t e t e n d i n io c a p s u l e con i s c h e m i a | | | | | | | | | | | 2 0 0 9 0 5 1 3 1 2 0 0 0 0 | | |e1e f703cd06e10364302ab692246b17a1e6d5f fe

Fig. 7. HL7 v2.3 Observation (ORUˆR01) message for diabetes. (Source:Progetto Sinapsis PDTA)

IV. CASE STUDY: HL7-BASED GP/HS INTEGRATIONSERVICES

Hereafter, we present a GP/HS integration project, whichtakes into account different integration aspects. In particular,it comprises the extension/integration of an existing projectMITO.SI [42] Modulo Interconnessione Territorio Ospedalein provincia di Siena; Accordo ASL7 Siena / Coop Medici2000 and the project proposal CSI-DIAB Cartella SpecialisticaIntegrata - Diabete; AOU Careggi Firenze/ Medici di MedicinaGenerale ASL 10 Firenze [43]. The GP integration aspectsrelated to the CDA Rel. 2 Prescription has been described in[44].

The project deals with the realization of integration servicesfor General Practitioners (in Italian MMG, Medici di MedicinaGenerale and PLS, Pediatri di Libera Scelta ) and HospitalSpecialists (in Italian SO Specialisti Ospedalieri) accordingto the technical specifications of e.Toscana Compliance [45]and the infrastructure CART Cooperazione Applicativa dellaRegione Toscana [46], that enables the development of inter-operable and cooperative software solutions, and the CartaSanitaria Elettronica Tuscany Region Project [47].

A scheme with the various systems to be integrated isdepicted in Figure 8. The main services offered are specifiedin details in the workpackage list shown in Table III.

Workpackages Services

WP1 Public Health Local Person/Patient Registry - HL7v3Integration

WP2 Public Health Code Systems - OID Integration

WP3 Electronic Prescription Document - CDA Originatorand Recipient

WP4 Patient Summary/Medical Record - CDA Originatorand Recipient

WP5 Provide Patient Summary/Medical Record to EHR

WP6 Retrieve Patient Summary/Medical Record fromEHR

WP7 Provide E-Prescription Document to SARWP8 Retrieve E-Prescription Document from SARWP9 GP/HS Medical Record HL7 Integration

WP10 Security and Privacy - Carta sanitaria elettronicaregionale

WP11 Self Audit and Clinical Governance

TABLE IIIWORKPACKAGES OF THE INTEGRATION SERVICES - GP/HS PROJECT

The horizontal integration of the different Electronic Med-ical Record systems for General Practitioners has been takeninto account by the MITO.SI project. We extend it, with avertical integration to the EHR, both at local and regionalpublic health organization level. Both the e-Prescription andthe Patient Summary are implemented according to the CDARel.2 standard.

Collecting and comparing data for self-audits and clinicalgovernance is also considered for General Practitioners, asrequired by the CCM. TRX-ANR is the XML dataset sharedin the GP ANR (National Research Area), based on the TRX-CICoM specifications, used in the clinical audit process andfor epidemiological studies on chronic diseases.

Moreover, according to CCM, in order to develop theexchange of medical records between Hospital Specialistsand General Practitioners, we consider a vertical integrationthrough an interface (HL7-based) of the Clinical InformationSystems, and an integration (CDA Rel. 2) with the EHR forthe Hospital Specialists. The TRX-PDTA is the XML datasetcommon to all PDTA used for the exchange and the sharingof the medical record information.

The interface to access the Person/Patient Registry is imple-mented according to the HL7v3-based regional specifications[48], [49]. We need also to implement the integration withthe Public Health/Regional Code systems and Identificationschema, according to the HL7 OIDs (Object Identifiers) [37].

The module Hospital Specialist (HS)Medical Record, depicted in Figure 8, is detailedwith all its connections and HL7 interfaces in Figure 9.Notice that we are considering the main Chronic illness suchas Diabetes, Heart disease, Hypertension, Chronic ObstructivePulmonary disease and Brain stroke.

In Figure 10 the scheme of the Person/Patient RegistryHL7v3 Integration is drawn. It refers to WP1 and WP2workpackages. As shown, an integration is needed between theperson/patient registry of the GP/HS Medical Record systemsand the Public Health person/patient registry. This integrationis implemented through two services: an HL7 patient registryinterface using the regional Common Terminology (OID); a

152

Fig. 8. Integration Schema - GP/HS Project

Fig. 9. HS Medical Record (Expanded Chronic Care model): Details onconnections and interfaces

consumer of the Public Health person/patient registry servicethrough the Local Application Node to the CART infrastruc-ture.

Fig. 10. Person/Patient Registry HL7v3 Integration - GP/HS Project

In Figure 11 the integration scheme of the CDA Rel.2Patient Summary is shown, referring to WP4,WP5,WP6 andWP2 workpackages. This scheme shows how the variousservices interact to provide (and retrieve) Patient Summarydocuments to (from) the EHR, at regional and local level.

Fig. 11. CDA Rel.2 Patient Summary - GP/HS Project

V. FINAL REMARKS

The proposed GP/HS project represents, at regional level,an example of integration/interoperability for the Patient Sum-mary documents, the Prescription documents and the PDTAmedical records within the Electronic Health Record. This inline with the Italian IPSE [50] and European epSOS (Euro-pean Patients Smart Open Services [51]) projects, with theirinitial focus on both patient summary/emergency data sets andmedication record/ePrescribing solutions. Tuscany Region andvarious other Italian regions are involved in the [50] project;and Italy with Lombardia Region and many European member

153

states are involved in [51]. The analysis carried out in theseprojects pointed out that the European situation is diversifiedwith some regions and countries more advanced than others interms of their capacity to implement EHR solutions. In Italy,the situation from region to region is also very dissimilar. Italso highlights that interoperability among different systemsis the key to enhance the possibility of these services beingprovided across national or regional borders.

Future developments of the diagnostic and therapeutic paths(PDTA) need a standardization of the clinical data set witha strong interaction among Hospital Specialists and GeneralPractitioners with the participation of the scientific and medicalsociety for the different specialties related to the variouschronic diseases. It is also needed a standard definition of thePDTA document structure according to CDA Rel.2 to ensureinteroperability within the EHR, in consideration also of theTSE activity [10]. An ongoing HL7 international project ondefinition of minimum data set and data standards in EHRsystems for diabetes assessment in outpatient clinic settings isdocumented in [52].

The development and localization of the Patient Summaryhas been started with the involvement of the GP. The work ofthe HL7 Italia Group [25] is actually in progress and TSEhas recently released a draft of technical specifications forthe creation of the Profilo Sanitario Sintetico according to thestandard CDA Rel.2 [53].

ACKNOWLEDGMENT

The authors would like to thank HL7 Italia and the colleaguesof the Gruppo di Progetto HL7 Italia IG CDA2 Profilo SanitarioSintetico for the localization activity, here partially reported.

REFERENCES

[1] Rapporto 2008 Osservatorio ICT & CIO in Sanità MIP Politecnico diMilano, Maggio 2008.

[2] Rapporto 2010 Osservatorio ICT in Sanità MIP Politecnico di Milano,Maggio 2010. http://www.osservatori.net/ict_in_sanita

[3] ICIC Improving Chronic Illness Care.http://www.improvingchroniccare.org

[4] HL7v3 Standard, Health Level Seven International, http://www.HL7.org[5] Piano Sanitario Regionale 2008-2010 Consiglio Regionale della Toscana,

Deliberazione n.53 del 16 luglio 2008.[6] Le aziende sanitarie verso il fascicolo sanitario elettronico: stato del arte

e prospettive. Florence, January 15, 2010, http://www.fiaso.it[7] Piano di e-government 2012. Obiettivo 4: Salute

http://www.e2012.gov.it/egov2012/?q=content/obiettivo-4-salute[8] TSE - IBSE: Strategia architetturale per la Sanità Elettronica, v01.00,

31/03/2006:http://www.sanitaelettronica.gov.it/xoops/modules/docmanager/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. 1.0http://www.innovazionepa.gov.it/media/563457/infse - linee guida e speci-fiche tecniche_v1.0.pdf

[10] TSE - Tavolo di lavoro permanente per la Sanità Elettronica delle Regionie delle Provincie Autonome. Specifiche tecniche per la creazione delDocumento di Referto secondo lo standard HL7-CDA Rel. 2 Versione1.1, 27/01/2010 http://www.innovazionepa.gov.it/media/354238/referto-cda2-v1.1.pdf

[11] HL7 Clinical Document Architecture Release 2.0, Normative Edition,May 2005, ANSI/HL7 CDA,R2-2005 4/21/2005, ISO/HL7 27932:2008.

[12] Ministero del Lavoro, della Salute, e delle Politiche Sociali, Mattone 09,Realizzazione del Patient File , Principi generali sul Fascicolo SanitarioPersonale, 11 Luglio 2007: http://www.mattoni.ministerosalute.it/mattoni/paginaInternaMenuMattoni.jsp?id=12&menu=mattoni

[13] IT Infrastructure Technical Frameworkhttp://www.ihe.net/Technical_Framework/index.cfm#IT

[14] TSE Una Politica per la Sanità Elettronica, 31/03/2005http://www.sanitaelettronica.gov.it/se/documenti/TSE Politica Condivisaper la Sanità Elettronica.pdf

[15] HL7 Implementation Guide:CDA Release 2, Continuity of Care Doc-ument (CCD) A CDA implementation of ASTM E2369.05 StandardSpecification for Continuity of Care Record (CCR), April 01, 2007http://www.hl7.org/library/General/HL7_CCD_final.zip

[16] IHE Patient Care Coordination (PCC) Technical Framework,Revision5.0, 2009.08.10http://www.ihe.net/Technical_Framework/index.cfm#pcc

[17] HL7 Implementation Guide for CDA Release 2: History and Physical(H&P) Notes (US Realm), DSTU, August 2008.

[18] HITSP Summary Documents Using HL7 Continuity of Care (CCD)Component HITSP/C32, Version 2.5 July 8, 2009.

[19] HITSP CDA Content Modules Component HITSP/C83, Version 1.1 July8, 2009.

[20] HL7 Implementation Guide for CDA Release 2, Level 1 and 2, CareRecord Summary (US Realm) Final Text, June 23, 2006.

[21] Carta Regionale dei Servizi SISS Secondo Stadio Specifiche di StrutturaCDA2, Patient Summary Regione Lombardia, Versione 2.0, 15/05/2009.

[22] LUMIR, Lucania Medici in Rete Patient Summary e documentazioneclinica Regione Basilicata, Versione 1.07.

[23] Rete di Medici di Medicina Generale, Progetto esecutivo definitivoSpecifiche tecniche per la produzione del Patient Summary in formatoHL7 Versione 3 CDA Rel.2 Regione Abruzzo.

[24] RFC 133 Carta Sanitaria Regione Toscana. Patient Summary (ProfiloSanitario Sintetico), Versione 1.01 del 29.09.2009.

[25] HL7 Italia Implementation Guide Clinical Document Architecture (CDA)Rel. 2, Profilo Sanitario Sintetico (Patient Summary), (IT Realm), standardinformativo, Bozza (WIP), 02 marzo 2010.

[26] Delibera n. 894 del 03.11.2008 PSR 2008.2010: Progetto Dalla medicinadi attesa alla sanità d’iniziativa. Approvazione indirizzi per attuazionedella sanità di iniziativa a livello territoriale e per la gestione dei percorsiterritorio - ospedale - territorio.

[27] Delibera n.716 del 03.08.2009 PSR 2008.2010, punto 4.3.1. Progetto perattuazione della sanità d’iniziativa a livello territoriale.

[28] Delibera n. 467 del 03.06.2009 Approvazione schema di Accordo traRegione Toscana e organizzazioni sindacali rappresentative della MedicinaGenerale sul ruolo della Medicina Generale nella attuazione del PSR2008.2010.

[29] Parere n. 1/2009 Percorsi territorio - ospedale - territorio. Programma diformazione e informazione sensibilizzazione su sanità di iniziativa e ges-tione delle malattie croniche. Chronic Care Model: Ruolo e competenzedei diversi attori.

[30] Parere n. 52/2008 Percorsi Territorio - Ospedale - Territorio: percorsiassistenziali.

[31] Parere n. 37/2008 Percorsi Territorio - Ospedale - Territorio: trasmissioneparere.

[32] T. Bodenheimer, E.H. Wagner, K. Grumbach, Improving primary carefor patients with chronic illness, JAMA 2002; 288:1775 79.

[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 ExpandedChronic Care Model, Hospital Quarterly, Vol.7, No 1, 73,82, 2003.

[35] J. De Maeseneer et al., Primary health care as a strategy for achievingequitable care, a literature review commissioned by Health SystemsKnowledge Network, WHO, March 2007.

[36] HL7 Italia CDA Working Group, Clinical Document Architecture (CDA)Rel.2, Sezione Header, Guida Implementativa di Localizzazione Italiana,Versione 1.0, Settembre 2008: www.hl7Italia.it

[37] HL7 Italia Identificazione Object Identifiers (OID), Versione 2.0, 26maggio 2009: www.hl7Italia.it

[38] C.I.Co.M. Consorzio per Interoperabilitá e la Cooperazione Medica.http://www.consorziocicom.it/modules.php?op=modload&name=Altro&file=index&req=contatti

[39] Co.S Consorzio di Consorzi regionali di Cooperative di medici difamiglia. http://www.cos.it/

[40] Progetto IGEA - Requisiti Informativi per un sistema di gestioneintegrata del diabete mellito di tipo 2 nell’adulto: documento di indizzohttp://www.epicentro.iss.it/igea/en/default.asp

[41] SINAPSIS (Suite INterconnesione Avanzata Per Sistemi InformativiSanitari) https://osmconnector.koine-servizi.it/

154

[42] Progetto MITO.SI Moduli di Interconnes-sione Territorio Ospedale in Provincia di Siena:http://www.etinnova.it/images/pages/3144/15072009124104319_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: LocalizationExperience and GP Integration Project. IEEE Workshop on Health CareManagement, Venice, February 2010.

[45] e.Toscana compliance: http://web.rete.toscana.it/eCompliance/portale/loadStaticPage?staticPage=index.html

[46] CART: http://www.cart.rete.toscana.it/portal/view/index.jsp.[47] Delibera n.125 della Giunta regionale della Toscana del 23 febbraio

2009, PSR 2008/2010, punto 4.1.2. Approvazione progetto Carta SanitariaElettronica

[48] e.Toscana compliance RFC85.4 Servizi Anagrafe Persone HL7v3 (Stan-dard 2009.06.18).

[49] e.Toscana compliance RFC86.4 Servizi Generale Anagrafe SanitariaHL7v3 (Standard 2009.06.18).

[50] IPSE: Sistema per la Interoperabilità nazionale delle soluzioni di Fasci-colo Sanitario Elettronico: Patient Summary e ePrescription.

[51] epSOS Project (European Patients Smart Open Services).http://www.epsos.eu/epsos-home.html

[52] EHR Diabetes Data Strategy http://wiki.hl7.org/index.php?title=EHR Di-abetes Data Strategy

[53] TSE - Tavolo di lavoro permanente per la Sanità Elettronica delleRegioni e delle Provincie Autonome. Specifiche tecniche per la creazionedel Profilo Sanitario Sintetico secondo lo standrad HL7-CDA Rel. 2,21/06/2010, Bozza 7.1http://www.innovazionepa.gov.it/media/563465/specifiche tecniche delprofilo sanitario sintetico in formato hl7 cda v.2 (bozza).pdf

155