HL7v3 CDA Rel.2 Patient Summary and Chronic Care Model: Localization Experience and GP/HS Integration Project
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
HL7v3 CDA Rel.2 Patient Summary and Chronic
Care Model: Localization Experience and GP/HS
Integration Project
Renato Calamai Laura Giarré
eHealthTech Dias-Università di Palermo
Via delle Cantine 27 50041 Calenzano (FI) - Italy Viale delle Scienze 90128 Palermo - Italy
Email: renato.calamai@ehealthtech.it Email: giarre@unipa.it
Abstract—The localization experience for the Patient Sum- a patient’s healthcare, represents one of the main elements of
mary, based on the Health Level Seven Version 3 (HL7v3) Clinical the Electronic Health Record (EHR) systems.
Document Architecture, Release 2 (CDA Rel.2), is presented.
An overview of the Chronic Care Model (CCM) is introduced
The integration of the Clinical Information Systems, be-
with particular attention to the clinical information systems, tween hospital and primary care is one of the essential aspects
in order to organize patient and population clinical data by of the Chronic Care Model, as reported in [5] for Tuscany
sharing information among healthcare providers in management Region, for the development of diagnostic and therapeutic
of chronic diseases. We propose, as case study, a project for the paths Percorsi Diagnostico Terapeutici Assistenziali (PDTA).
integration of various services for General Practitioners (GP) and
Hospital Specialists (HS), accessing the Electronic Health Record In a recent FIASO (Federazione Italiana Aziende Sanitarie
(EHR), implementing the Patient Summary and managing the e Ospedaliere) report [6] an optimistic picture of the Italian
exchange of Chronic Care medical records. This project is in situation is overviewed with regards to the knowledge of the
line with the state of the art in the normative referring context EHR (71% of GPs and 67% of HSs) and a spread use of EHR
for the Italian healthcare, both at national and regional level and Patient Summary reported as 7 regions among 20.
(Tuscany Region).
Index Terms—e-Health, HL7, Interoperability, Chronic Care
The paper is organized as follows: in the following we
Model, Patient Summary, EHR present the referring normative and technological context with
a brief overview of the standard HL7v3 for the Clinical Docu-
ment Architecture (CDA) Rel.2, and the Chronic Care Model
I. I NTRODUCTION for the Clinical Information Systems; in section II we describe
New challenges in healthcare should be based [1], [2] on the experience with the CDA Rel.2 localization for Patient
a rationalization of administrative and managerial processes; Summary and in section III the experience in implementing
an improvement of the clinical and healthcare processes; a the CCM medical record; in section IV we describe a project
reduction of clinical risks; and an expanded Chronic Care of Integration for General Practitioners (GP) and Hospital
Model (CCM) [3] in order to overcome the deficiencies in Specialists (HS), accessing the EHR, implementing the Patient
current management of chronic disease. The Italian healthcare Summary and managing the exchange of Chronic Care medical
situation is characterized by an huge diffusion of hetero- records; and, finally, in section V we draw some final remarks.
geneous ad hoc applications and legacy systems in all the
administrative and clinical domains; a very low presence of A. Referring normative and technological context
advanced solutions (Service Oriented Architecture and Busi- The referring context for Italian e-health is primarily de-
ness Process Management); deficiency of guidelines both at scribed in the project of the Health objective for the Italian
regional and national level; and, finally, lack of applications plan e-Gov 2012 [7], including the project Medici in Rete
based on technological standards. One of the solution is the for the connection of the General Practitioners and the Pe-
use of innovative standards for the integration of the informa- diatricians with the regional infrastructures; and the project
tion systems and the implementation of application solutions Fascicolo Sanitario Elettronico (FSE) for the implementation
based on modern technological standards. The use of standard of a distributed solution for patient’s EHR (in Italian FSE),
enables the interoperability. Interoperability is the ability of at regional, national and European level. The technological
two or more systems or components to exchange information references have been published by the Tavolo permanente di
and to use the information that has been exchanged. We will Sanità Elettronica (TSE) composed by the regional represen-
refer to HL7v3 [4] as the most widely used standard for health- tatives, and coordinated by the Department Digitalizzazione e
care interoperability. The Patient Summary (in Italian Profilo Innovazione Tecnologica of the Innovation and Public Admin-
Sanitario Sintetico (PSS)), an electronic clinical document istration Ministry (Ministero della Pubblica Amministrazione
summarizing the most relevant clinical information facts about e Innovazione), with the participation of the Health Ministry
,(((
147
(Ministero della Salute) and DigitPA. These documents are community-based facilities and services. The normative refer-
related to architectural strategies for e-health; the regional EHR ring context at Tuscany Region level is the Piano Sanitario
guidelines [8]; the definition of the national EHR technological Regionale (PSR) 2008-2010 [5], specifically the objectives of
infrastructure (InFSE) [9]; and the technical specifications of proactive healthcare and the Chronic Care Model; the various
the electronic Medical Report, according to the standard HL7- bylaws of Regional Health Department [26], [27],[28]; and the
CDA Rel. 2, for the exchange of clinical data at national level opinions of the Regional Council Health Committee [29], [30],
[10], [11]. [31].
According to these projects, and also to Progetto Mattoni B. HL7 Version 3 CDA Rel.2
SSN (Servizio Sanitario Nazionale) Realizzazione del Patient
File [12], HL7 Version 3 has been indicated as the messaging Health Level Seven International (HL7) is the leading
standard in healthcare information exchange, and HL7-CDA global authority for healthcare information interoperability and
Rel. 2 as the standard for clinical documents exchange. The standards with members in over 55 countries. HL7 is "an ANSI
IHE-XDS profile (Cross-Enterprise Document Sharing) is also accreditated standard development organization dedicated to
suggested as one of the reference framework for registering and providing a comprehensive framework and related standards
sharing electronic health record documents between healthcare for the exchange, integration, sharing, and retrieval of elec-
enterprises [13]. tronic health information that supports clinical practice and
In the present work, we mainly focus on the Patient Sum- the management, delivery and evaluation of health services"
mary that is an important aspect in the GP systems integration [4]. HL7 Version 3 (HL7v3) is a reference paradigm for the
with the EHR. In the past, TSE started various regional projects syntactic-semantic interoperability. The HL7 V3 methodology
for the General Practitioners [14] Sanità Elettronica - Rete dei uses the Reference Information Model (RIM), the Data Types
Medici di Medicina Generale, including the Patient Summary, Specification, and the HL7 Vocabulary as its starting point. It
the electronic clinical document summarizing the most rele- then establishes a message development process for refining
vant clinical information facts about a patient’s healthcare, to and constrain the Reference Information Model to arrive at
support the continuity of care. Patient Summary is a document the Hierarchical Message Descriptor (HMD) that specifies a
of the EHR that must be created, updated and digital signed by number of messages called Message Types.
the GPs providing a snapshot in time containing the pertinent The following Figure 1 shows the refinement process spec-
clinical data, as the emergency data set. Patient Summary ified in the methodology. As diagrammed, the processes are
is developed according to the standard CDA Rel. 2 and is used to derive one or more Domain Message Information
based on the HL7 Continuity Care Document (CCD), a CDA Models (D-MIM) from the RIM. Each such model represents
implementation of ASTM Continuity of Care Record (CCR) the set of concepts embodied in the individual Refined Mes-
[15]; the IHE Patient Care Coordination (PCC) [16]; and sage Information Model (R-MIM) needed to represents the
[17],[18],[19],[20]. requirements of a particular HL7 domain.
The need to identify synthetic and effective tools to fa-
cilitate 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
Fig. 1. Refinement Process for defining messages based on the HL7 RIM
[22], RMMG Regione Abruzzo [23]. In Tuscany Region, Patient (Source: Health Level Seven, Inc.)
Summary is defined in the RFC 133 [24], according to [25].
The exchange and sharing of clinical information in chronic The HL7 Clinical Document Architecture (CDA) is
illness is an other important aspect of the GP Integration a document markup standard that specifies the struc-
Project with the Hospital Specialist. The integration of the ture and semantics of clinical documents for the pur-
Clinical Information Systems, with particular attention to the pose of exchange. CDA documents are encoded in Ex-
GP Medical Records with the Hospital Specialist Medical tensible Markup Language (XML). A CDA document is
Records represents one of the essential elements in implement- wrapped by the element, and con-
ing the Chronic Care Model (CCM). This aspect is in line with tains a header and a body . The header lies between the
the development of a proactive healthcare that is based on and the el-
an integrated management of the diagnostic and therapeutic ements, and identifies and classifies the document and provides
paths (PDTA) between hospitals and primary care with the information on authentication, the encounter, the patient, and
148
the involved providers. The body contains the clinical report, interactions. The fundamental functions to be guaranteed are:
and can be either an unstructured blob, or can be comprised providing reminders and alerts for providers and patients;
of structured markup. A CDA document section is wrapped identifying relevant patient subpopulations according to their
by the element. Each section can contain a chronic illness for proactive care; facilitating individual patient
single narrative block , and any number of CDA entries and care planning; sharing information with providers and patients;
external references. The CDA narrative block is wrapped by and, finally, monitoring performance of team with respect to
the element within the element, and the chronic care illness indicators.
must contain the human readable content to be rendered. The Chronic Care Model will require a transformation
of health care, from a system that is essentially reactive -
C. Chronic Care Model
responding mainly when a person is sick - to one that is
The Chronic Care Model summarizes the basic elements proactive and focused on keeping a person as healthy as
for improving chronic illness care in health systems at the possible. This model has been promoted by the World Health
community, organization, practice and patient levels. This Organization [33] and exploited in many countries such as
model, elaborated by Prof. Wagner of the Mac-Coll Institute Canada, Holland, Germany, United Kingdom, Denmark. In
for Healthcare Innovation [3], [32], identifies the essential Tuscany Region this model has been used as the basis for
elements of a health care system that help high-quality chronic the Expanded Chronic Care Model [34],[35] where the single
disease care, such as diabetes, heart disease, hypertension, patient takes a more informed role inside the community and
chronic obstructive pulmonary disease. These elements are where the General Practitioner clinical aspects are integrated
- Community resources with those of the public health.
- Organization of Health Systems
- Self-management support II. A N EXPERIENCE IN LOCALIZING THE CDA R EL .2 FOR
- Delivery system design PATIENT S UMMARY
- Decision support Localization is the process of defining new HL7 Version 3
- Clinical information systems Message Types by a process that includes both the constraint
In Figure 2, the model is depicted with reference to the six process and an extension process that adds new concepts to
main elements and their interactions. The improved outcomes the base Message Type. Any local HL7 affiliated organization
needs to adapt the standard to the national or regional require-
ments. 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 docu-
ment 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
Fig. 2. Care Model (Source: The MacColl Institute - ACP-ASIM Journals continuity of care. The PSS is a document satisfying some
and Books)
requirements:
of this model are productive interactions between an informed - it must be synthetic and contain only the essential infor-
and activated patient and a prepared and proactive multi- mation;
professional health care team. Informed patients have sufficient - it must have a single author, the General Practitioners/-
information to become a wise decision-maker related to their Pediatricians creating and updating it;
illness and they also need to be activated by understanding the - it is not clinically specialized to be used in different
importance of their role in managing the illness. A prepared scenarios (Emergency, Chronic Care,..);
team is a practice team that is organized, trained, and equipped - it does not have a specific predefined recipient;
to conduct productive interaction. A productive interaction is - it must be only one and there must be only one PSS for
one that assures that patient needs for evidence-based clinical each patient inside the EHR.
and behavioral care information and support to become better The compliance requirements of Patient Summary are based
self-managers, and monitoring over time are met, as reported on the CCD, the IHE Patient Care Coordination and the Italian
in [3]. (IT) realm templates. The templates define the constraints for
Clinical information systems are the crucial factor in im- document, section, clinical statement and entry levels. More-
proving chronic illness care with their clinical database con- over the header must be compliant with the CDA Rel. 2 Header
taining the critical information necessary to get productive as defined by HL7 specifications and localized by HL7 Italia
149
CCD Section Requirements data defining the patient’s genetic relatives that have a
Purpose SHALL NOT potential impact on the patient’s healthcare risk profile.
Payers SHALL NOT
Medical Equipment RECOMMENDED • Social History: section containing the patient’s occupa-
Immunization OPTIONAL tional, personal (e.g. lifestyle), social and environmental
Vital Signs OPTIONAL history. Social history can have significant influence on
Results RECOMMENDED
Procedures OPTIONAL a patient’s physical, psychological and emotional health
Encounters OPTIONAL and wellbeing.
Plan of Care OPTIONAL
Advance Directives SHALL NOT
In the following, the CDA body for Alerts and Medications
Functional Status OPTIONAL sections are reported as an example of localization.
Problems REQUIRED
Family History OPTIONAL Alerts
Social History OPTIONAL
Alerts REQUIRED The information related to allergies and pharmacological
Medications REQUIRED reaction are listed in the section named with the LOINC
History of Pregnancies OPTIONAL code 48765-2 (Allergies, adverse reactions, alerts). The general
TABLE I structure of the Alerts section is reported in Figure 3.
L IST OF REQUIREMENTS FOR THE INCLUSION OF THE CCD SECTIONS
(S OURCE : HL7 I TALIA )
< component >
< i d r o o t = ’ $ID_SEZ ’ / >
[36]. Patient Summary also follows the coding specification < c o d e c o d e = ’ 48765−2 ’ d i s p l a y N a m e = ’ A l l e r g i e , R e a z i o n i Avverse , A l l a r m i ’
c o d e S y s t e m = ’ 2 . 1 6 . 8 4 0 . 1 . 1 1 3 8 8 3 . 6 . 1 ’ codeSystemName= ’LOINC ’ / >
defined in the HL7 Italia document Identificazione Object < 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 >
Identifiers (OID) [37]. $NARRATIVE_BLOCK
Patient Summary has been defined according to the CDA < !−− M o l t e p l i c i t à 1 . . N − Problem A c t −−>
R-MIM. It is structured in a Header and a CDA Body, human $ALERT
readable (level 2) and machine readable (level 3).
< / component >
The CDA Body, structured in specific sections, contains the
patient clinical data. The various elements in the
body may contain more than one element of type Fig. 3. Alerts: general structure of the section (Source: HL7 Italia)
that could be narrative or partially/totally coded. Hereafter,
we assume that the information contents of the coded entry The information regarding an alarm is represented through
will always be reported also as text in the narrative block. an act derived from the template "Allergy and Intolerance
Not all the CCD sections have been implemented in the CDA Concern". The general structure of the entry Alarm is reported
Body. Table I reports which section is required, optional or not in Figure 4.
required, up to now.
We report the CCD sections that are now under discussion < a c t c l a s s C o d e = ’ACT ’ moodCode= ’EVN ’ >
in the Patient Summary localization.
< !−− 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 g u i d a −−>
• Alerts: section collecting alarms relative to any allergies,
< i d r o o t = ’ $ID_SEZ ’ / >
adverse reactions, and alerts that are pertinent to the < c o d e n u l l F l a v o r = ’NA’ / >
< s t a t u s C o d e c o d e = ’ $STATUS_CODE ’ / >
patient’s current or past medical history.
< !−− RICHIESTO −−>
• Medications: section collecting all the actual prescribed
< !−− OPZIONALE −−>
pharmacological therapies. At a minimum, the currently < h i g h v a l u e = ’ $HIGH_TS ’ / >
active medications should be listed, with an entire medica- < !−−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 ’ >
tion history as an option, particularly when the summary $ALRT_CONCERN | $OINT_CONCERN | $NO_ALLERGIES
document is used for comprehensive data export.
• Immunizations: section defining a patient’s current im-
munization status and pertinent immunization history. Fig. 4. Alerts: general structure of the clinical statements (Source: HL7 Italia)
The section should include current immunization status,
and may contain the entire immunization history that is The detailed information for a generic alarm or an allergy
relevant to the period of time being summarized. or some intolerance, are listed as an Observation element.
• Problems: section deputed to summarize the relevant Further information, as for example the allergy status or
clinical problems, including the main pathologies. At a the alert severity, can be included as specific classes referred
minimum, all pertinent current and historical problems through entryRelationship.
should be listed. CDA Rel.2 represents problems as
Observations. Medications
• Family History: section collecting the family medical All the information related to prescriptions and substance
history, relevant for the patient risks. This section contains administration are listed in the section named with LOINC
150code 10160-0 (Medications). The general structure of the Fields Description
Medications section is reported in Figure 5. trxIdentificazione Patient identification
trxAnagrafica Patient registry
trxAnamnesiFamiliare Family History
< component > trxEsenzione Patient exemption
trxIntollFarmaco Alerts, adverse reaction
trxMalattiaRilevante Pathology, Chronic Disease
trxMonitoraggio Vital Signs
< i d r o o t = ’ $ID_SEZ ’ / > Prescription (laboratory)
< c o d e c o d e = ’ 10160−0 ’ d i s p l a y N a m e = ’HISTORY OF MEDICATION USE ’
trxPrescrizione
c o d e S y s t e m = ’ 2 . 1 6 . 8 4 0 . 1 . 1 1 3 8 8 3 . 6 . 1 ’ codeSystemName= ’LOINC ’ / > trxRisultato Results
< t i t l e >Terapie
trxPrescrizioneEsStru Prescription (instrumental exams)
$NARRATIVE_BLOCK trxPrescrizioneFarmaco Prescription (medications)
< !−− 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 F a r m a c o l o g i c a −−> trxPrescrizioneVisitaSpecialistica Prescription (specialist visit)
trxRicoveroOspedaliero Hospitalization
$MEDICATION | $NO_MEDICATION
trxStileVita Social History
trxVaccinazione
< / component >
Immunizations
trxVisitaMMG General Practitioner visit
trxXtraDati Specific application data
Fig. 5. Medications: general structure of the section (Source: HL7 Italia) TABLE II
T RX -PDTA PRINCIPAL FIELDS AND DESCRIPTIONS
The information regarding a medication activity is rep-
resented through a substanceAdministration derived
from the template "Medication Activity". The general structure
Health organization. In order to implement the exchange and
of the medication activity entry is reported in Figure 6.
sharing of medical records between hospital and primary care
for the management of the diagnostic and therapeutic paths
< 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 ’ >
(PDTA), is important to specify both the clinical data set and
the technological interfaces and messaging, according also to
< i d r o o t = ’ $ID_SEZ ’ / > the regional guidelines.
< r e f e r e n c e v a l u e = ’ #$REF_MED ’ / >
Clinical data set
< s t a t u s C o d e code= ’ completed ’ / >
< !−− 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 n o t o d e v e e s s e r e v a l o r i z z a t o a UNK −−>
Up to now, there are no national/regional standard speci-
< e f f e c t i v e T i m e x s i : t y p e = ’ IVL_TS ’ >
fications for the definition of the clinical data set in PDTA
< !−− OPZIONALE −−>
< h i g h v a l u e = ’ $HIGH_TS ’ | n u l l F l a v o r = "UNK" / >
for the various chronic pathologies. Here, we consider the
< !−−OPZIONALE u s a t o p e r 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−−>
TRX-PDTA, a possible solution based on TRX-CICoM spec-
< 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 ’ >
ifications. CICoM (Consorzio per la Interoperabilità e la
$POSOLOGIA
Cooperazione Medica) [38] is an Interoperability and Medical
< !−−OPZIONALE −−>
< r o u t e C o d e c o d e = ’ $COD_VIA_SOMM ’ / >
Cooperation Consortium of GP software providers. TRX-
< !−−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 >
PDTA is an XML dataset common to all PDTA, proposed
< !−−OPZIONALE −−>
< a p p r o a c h S i t e C o d e c o d e = ’ $COD_APP_COD ’ >< / a p p r o a c h S i t e C o d e >
within the Co.S. (Consorzio Sanità) [39], a GP Cooperative
< !−−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 >
Consortium. This dataset is used in the horizontal integration
$FARMACO
among the different GP Medical Records systems in the
< / consumable>
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
Fig. 6. Medications: general structure of the clinical statements (Source: HL7
Italia) be further detailed and the various fields have to be specified.
As a national example of guidelines for the management
Among the possible templates belonging to the medication of chronic illness we report the IGEA Project Integrazione
family, in the Patient Summary now it is considered only the Gestione e Assistenza per la malattia diabetica, a chronic
normal dosing. This template identifier is used to identify med- disease management project for people with diabetes. It con-
ication administration events that do not require any special tains recommendations for an integrated management of the
processing. type 2 diabetes mellitus in adults, addressing clinical and
organizational requirements and information requirements with
III. A N EXPERIENCE IN IMPLEMENTING THE CCM: GP/HS
the definition of clinical and system indicators and a data
M EDICAL R ECORDS
dictionary [40].
Clinical information systems are one of the crucial factors
in improving the continuity of care for chronic illnesses, such Interface and messaging
as diabetes, heart disease, hypertension and chronic obstructive Both in the Hospital Specialist area and in the Primary Care
pulmonary disease. Inside the clinical information systems, the area the integration allows the operators to use its own medical
clinical aspects summarized in the medical records need to record systems in order to manage and archive the information
be integrated among the General Practitioners and the Public related to the specific clinical dataset. As an example, the
151diabetes medical record for the Hospital Specialist, and the Workpackages Services
personal Medical Record for the General Practitioner. The Public Health Local Person/Patient Registry - HL7v3
WP1
Integration
considered integration is based on a PDTA service (Progetto WP2 Public Health Code Systems - OID Integration
Sinapsis [41]) for the exchange and sharing of administrative Electronic Prescription Document - CDA Originator
WP3
and Recipient
and clinical data. The service operations comprise the clinical Patient Summary/Medical Record - CDA Originator
WP4
data sending, the query/response for the patient lists and the and Recipient
specialist visit lists, and the clinical data retrieving. To guar- WP5 Provide Patient Summary/Medical Record to EHR
WP6 Retrieve Patient Summary/Medical Record from
antee interoperability, the interactions of the PDTA services EHR
are based on HL7 messaging. As an example, in Figure 7 an WP7 Provide E-Prescription Document to SAR
WP8 Retrieve E-Prescription Document from SAR
HL7 v2.3 R01-unsolicited transmission of observation message WP9 GP/HS Medical Record HL7 Integration
(ORU) for diabetes is reported. WP10
Security and Privacy - Carta sanitaria elettronica
regionale
WP11 Self Audit and Clinical Governance
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 l v f n c 2 9 m 0 5 c 5 5 2 a ^^N^CODFISC~11111111111111111111^^^CODSAN~ TABLE III
^^^ STP ~^^^SGP | | _Cognome ^ Esempio Bambino | | 1 9 8 6 0 2 1 1 1 2 0 0 0 0 |M | | | | | | | | | | | | | | | | | | W ORKPACKAGES OF THE I NTEGRATION SERVICES - GP/HS P ROJECT
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 ^ E m o g l o b i n a 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 | | | | | | | | | | |
The horizontal integration of the different Electronic Med-
20090513120000|||
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 −
ical Record systems for General Practitioners has been taken
laser trattata | | | | | | | | | | | 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 | | |
into account by the MITO.SI project. We extend it, with a
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 A v a n z a t a | | | | | | | | | | | 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 | | |
vertical integration to the EHR, both at local and regional
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 e
d 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 | | |
public health organization level. Both the e-Prescription and
OBX | 1 1 | ST | CL138 ^ U l c e r a − I n a t t o − 0D l e s i o n e p r e− o p o s t u l c e r a t i v a
c o m p l e t a m e n t e 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
the Patient Summary are implemented according to the CDA
ischemia | | | | | | | | | | | 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 − I n a t t o − IC l e s i o n e s u p e r f i c i a l e
Rel.2 standard.
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
ischemia | | | | | | | | | | | 2 0 0 9 0 5 1 3 1 2 0 0 0 0 | | |
Collecting and comparing data for self-audits and clinical
OBX | 1 3 | ST | CL145 ^ U l c e r a − I n a t t o − I I C 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 i
o 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 | | |
governance is also considered for General Practitioners, as
e1ef703cd06e10364302ab692246b17a1e6d5ffe
required by the CCM. TRX-ANR is the XML dataset shared
in the GP ANR (National Research Area), based on the TRX-
Fig. 7. HL7 v2.3 Observation (ORU ˆ R01) message for diabetes. (Source: CICoM specifications, used in the clinical audit process and
Progetto Sinapsis PDTA) for epidemiological studies on chronic diseases.
Moreover, according to CCM, in order to develop the
exchange of medical records between Hospital Specialists
IV. C ASE S TUDY: HL7- BASED GP/HS INTEGRATION and General Practitioners, we consider a vertical integration
SERVICES
through an interface (HL7-based) of the Clinical Information
Hereafter, we present a GP/HS integration project, which Systems, and an integration (CDA Rel. 2) with the EHR for
takes into account different integration aspects. In particular, the Hospital Specialists. The TRX-PDTA is the XML dataset
it comprises the extension/integration of an existing project common to all PDTA used for the exchange and the sharing
MITO.SI [42] Modulo Interconnessione Territorio Ospedale of the medical record information.
in provincia di Siena; Accordo ASL7 Siena / Coop Medici The interface to access the Person/Patient Registry is imple-
2000 and the project proposal CSI-DIAB Cartella Specialistica mented according to the HL7v3-based regional specifications
Integrata - Diabete; AOU Careggi Firenze/ Medici di Medicina [48], [49]. We need also to implement the integration with
Generale ASL 10 Firenze [43]. The GP integration aspects the Public Health/Regional Code systems and Identification
related to the CDA Rel. 2 Prescription has been described in schema, according to the HL7 OIDs (Object Identifiers) [37].
[44]. The module Hospital Specialist (HS)
The project deals with the realization of integration services Medical Record, depicted in Figure 8, is detailed
for General Practitioners (in Italian MMG, Medici di Medicina with all its connections and HL7 interfaces in Figure 9.
Generale and PLS, Pediatri di Libera Scelta ) and Hospital Notice that we are considering the main Chronic illness such
Specialists (in Italian SO Specialisti Ospedalieri) according as Diabetes, Heart disease, Hypertension, Chronic Obstructive
to the technical specifications of e.Toscana Compliance [45] Pulmonary disease and Brain stroke.
and the infrastructure CART Cooperazione Applicativa della In Figure 10 the scheme of the Person/Patient Registry
Regione Toscana [46], that enables the development of inter- HL7v3 Integration is drawn. It refers to WP1 and WP2
operable and cooperative software solutions, and the Carta workpackages. As shown, an integration is needed between the
Sanitaria Elettronica Tuscany Region Project [47]. person/patient registry of the GP/HS Medical Record systems
A scheme with the various systems to be integrated is and the Public Health person/patient registry. This integration
depicted in Figure 8. The main services offered are specified is implemented through two services: an HL7 patient registry
in details in the workpackage list shown in Table III. interface using the regional Common Terminology (OID); a
152Fig. 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 infrastruc-
ture.
Fig. 11. CDA Rel.2 Patient Summary - GP/HS Project
V. F INAL R EMARKS
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 PDTA
medical records within the Electronic Health Record. This in
line with the Italian IPSE [50] and European epSOS (Euro-
pean 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;
Fig. 10. Person/Patient Registry HL7v3 Integration - GP/HS Project and Italy with Lombardia Region and many European member
153states are involved in [51]. The analysis carried out in these [13] IT Infrastructure Technical Framework
http://www.ihe.net/Technical_Framework/index.cfm#IT
projects pointed out that the European situation is diversified [14] TSE Una Politica per la Sanità Elettronica, 31/03/2005
with some regions and countries more advanced than others in http://www.sanitaelettronica.gov.it/se/documenti/TSE Politica Condivisa
terms of their capacity to implement EHR solutions. In Italy, per la Sanità Elettronica.pdf
the situation from region to region is also very dissimilar. It [15] HL7 Implementation Guide:CDA Release 2, Continuity of Care Doc-
ument (CCD) A CDA implementation of ASTM E2369.05 Standard
also highlights that interoperability among different systems Specification for Continuity of Care Record (CCR), April 01, 2007
is the key to enhance the possibility of these services being http://www.hl7.org/library/General/HL7_CCD_final.zip
provided across national or regional borders. [16] IHE Patient Care Coordination (PCC) Technical Framework,Revision
5.0, 2009.08.10
Future developments of the diagnostic and therapeutic paths http://www.ihe.net/Technical_Framework/index.cfm#pcc
(PDTA) need a standardization of the clinical data set with [17] HL7 Implementation Guide for CDA Release 2: History and Physical
a strong interaction among Hospital Specialists and General (H&P) Notes (US Realm), DSTU, August 2008.
[18] HITSP Summary Documents Using HL7 Continuity of Care (CCD)
Practitioners with the participation of the scientific and medical Component HITSP/C32, Version 2.5 July 8, 2009.
society for the different specialties related to the various [19] HITSP CDA Content Modules Component HITSP/C83, Version 1.1 July
chronic diseases. It is also needed a standard definition of the 8, 2009.
[20] HL7 Implementation Guide for CDA Release 2, Level 1 and 2, Care
PDTA document structure according to CDA Rel.2 to ensure Record Summary (US Realm) Final Text, June 23, 2006.
interoperability within the EHR, in consideration also of the [21] Carta Regionale dei Servizi SISS Secondo Stadio Specifiche di Struttura
TSE activity [10]. An ongoing HL7 international project on CDA2, Patient Summary Regione Lombardia, Versione 2.0, 15/05/2009.
[22] LUMIR, Lucania Medici in Rete Patient Summary e documentazione
definition of minimum data set and data standards in EHR clinica Regione Basilicata, Versione 1.07.
systems for diabetes assessment in outpatient clinic settings is [23] Rete di Medici di Medicina Generale, Progetto esecutivo definitivo
documented in [52]. Specifiche tecniche per la produzione del Patient Summary in formato
HL7 Versione 3 CDA Rel.2 Regione Abruzzo.
The development and localization of the Patient Summary [24] RFC 133 Carta Sanitaria Regione Toscana. Patient Summary (Profilo
has been started with the involvement of the GP. The work of Sanitario Sintetico), Versione 1.01 del 29.09.2009.
the HL7 Italia Group [25] is actually in progress and TSE [25] HL7 Italia Implementation Guide Clinical Document Architecture (CDA)
Rel. 2, Profilo Sanitario Sintetico (Patient Summary), (IT Realm), standard
has recently released a draft of technical specifications for informativo, Bozza (WIP), 02 marzo 2010.
the creation of the Profilo Sanitario Sintetico according to the [26] Delibera n. 894 del 03.11.2008 PSR 2008.2010: Progetto Dalla medicina
standard CDA Rel.2 [53]. di attesa alla sanità d’iniziativa. Approvazione indirizzi per attuazione
della sanità di iniziativa a livello territoriale e per la gestione dei percorsi
ACKNOWLEDGMENT territorio - ospedale - territorio.
[27] Delibera n.716 del 03.08.2009 PSR 2008.2010, punto 4.3.1. Progetto per
The authors would like to thank HL7 Italia and the colleagues attuazione della sanità d’iniziativa a livello territoriale.
of the Gruppo di Progetto HL7 Italia IG CDA2 Profilo Sanitario [28] Delibera n. 467 del 03.06.2009 Approvazione schema di Accordo tra
Sintetico for the localization activity, here partially reported. Regione Toscana e organizzazioni sindacali rappresentative della Medicina
Generale sul ruolo della Medicina Generale nella attuazione del PSR
R EFERENCES 2008.2010.
[1] Rapporto 2008 Osservatorio ICT & CIO in Sanità MIP Politecnico di [29] Parere n. 1/2009 Percorsi territorio - ospedale - territorio. Programma di
Milano, Maggio 2008. formazione e informazione sensibilizzazione su sanità di iniziativa e ges-
[2] Rapporto 2010 Osservatorio ICT in Sanità MIP Politecnico di Milano, tione delle malattie croniche. Chronic Care Model: Ruolo e competenze
Maggio 2010. http://www.osservatori.net/ict_in_sanita dei diversi attori.
[3] ICIC Improving Chronic Illness Care. [30] Parere n. 52/2008 Percorsi Territorio - Ospedale - Territorio: percorsi
http://www.improvingchroniccare.org assistenziali.
[4] HL7v3 Standard, Health Level Seven International, http://www.HL7.org [31] Parere n. 37/2008 Percorsi Territorio - Ospedale - Territorio: trasmissione
[5] Piano Sanitario Regionale 2008-2010 Consiglio Regionale della Toscana, parere.
Deliberazione n.53 del 16 luglio 2008. [32] T. Bodenheimer, E.H. Wagner, K. Grumbach, Improving primary care
[6] Le aziende sanitarie verso il fascicolo sanitario elettronico: stato del arte for patients with chronic illness, JAMA 2002; 288:1775 79.
e prospettive. Florence, January 15, 2010, http://www.fiaso.it [33] World Health Organization, Innovative care for chronic conditions,
[7] Piano di e-government 2012. Obiettivo 4: Salute Building blocks for action, 2002, Geneva.
http://www.e2012.gov.it/egov2012/?q=content/obiettivo-4-salute [34] U.J. Barr, S. Robinson, B. Marin Link, L. Underh ill, The Expanded
[8] TSE - IBSE: Strategia architetturale per la Sanità Elettronica, v01.00, Chronic Care Model, Hospital Quarterly, Vol.7, No 1, 73,82, 2003.
31/03/2006: [35] J. De Maeseneer et al., Primary health care as a strategy for achieving
http://www.sanitaelettronica.gov.it/xoops/modules/docmanager/ equitable care, a literature review commissioned by Health Systems
view_file.php?curent_file=361&curent_dir=39 Knowledge Network, WHO, March 2007.
[9] InFSE: Infrastruttura tecnologica del Fascicolo Sanitario Elettronico - [36] HL7 Italia CDA Working Group, Clinical Document Architecture (CDA)
Linee guida e specifiche tecniche. Data: 15/06/2010, Versione: v. 1.0 Rel.2, Sezione Header, Guida Implementativa di Localizzazione Italiana,
http://www.innovazionepa.gov.it/media/563457/infse - linee guida e speci- Versione 1.0, Settembre 2008: www.hl7Italia.it
fiche tecniche_v1.0.pdf [37] HL7 Italia Identificazione Object Identifiers (OID), Versione 2.0, 26
[10] TSE - Tavolo di lavoro permanente per la Sanità Elettronica delle Regioni maggio 2009: www.hl7Italia.it
e delle Provincie Autonome. Specifiche tecniche per la creazione del [38] C.I.Co.M. Consorzio per Interoperabilitá e la Cooperazione Medica.
Documento di Referto secondo lo standard HL7-CDA Rel. 2 Versione http://www.consorziocicom.it/modules.php?
1.1, 27/01/2010 http://www.innovazionepa.gov.it/media/354238/referto- op=modload&name=Altro&file=index&req=contatti
cda2-v1.1.pdf [39] Co.S Consorzio di Consorzi regionali di Cooperative di medici di
[11] HL7 Clinical Document Architecture Release 2.0, Normative Edition, famiglia. http://www.cos.it/
May 2005, ANSI/HL7 CDA,R2-2005 4/21/2005, ISO/HL7 27932:2008. [40] Progetto IGEA - Requisiti Informativi per un sistema di gestione
[12] Ministero del Lavoro, della Salute, e delle Politiche Sociali, Mattone 09, integrata del diabete mellito di tipo 2 nell’adulto: documento di indizzo
Realizzazione del Patient File , Principi generali sul Fascicolo Sanitario http://www.epicentro.iss.it/igea/en/default.asp
Personale, 11 Luglio 2007: http://www.mattoni.ministerosalute.it/mattoni/ [41] SINAPSIS (Suite INterconnesione Avanzata Per Sistemi Informativi
paginaInternaMenuMattoni.jsp?id=12&menu=mattoni Sanitari) 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: Localization
Experience and GP Integration Project. IEEE Workshop on Health Care
Management, 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 Sanitaria
Elettronica
[48] e.Toscana compliance RFC85.4 Servizi Anagrafe Persone HL7v3 (Stan-
dard 2009.06.18).
[49] e.Toscana compliance RFC86.4 Servizi Generale Anagrafe Sanitaria
HL7v3 (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 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 7.1
http://www.innovazionepa.gov.it/media/563465/specifiche tecniche del
profilo sanitario sintetico in formato hl7 cda v.2 (bozza).pdf
155You can also read
