Implementation of a Standard Service of Repository for Cardiological Unit S. De Faveri1, M. Giacomini1, S. De Nadai1, and F. Greco2 1
Department of Communication Computer and System Science, University of Genoa, Genoa, Italy 2 Information Technology Department, ASL 4 Chiavarese, Genoa, Italy
Abstract—Although electronic communication of clinical data between various actors in the healthcare domain seems crucial for a cost-effective patient treatment, it is mostly restricted to paper based documents. In order to meet the growing need for improved data communication, it is necessary to overcome the barriers of software heterogeneity and lack of standards, especially in cross-institutional shared care communication. HL7's clinical document architecture (CDA) is a tool to exchange any clinical document. In this paper we show how CDA can be used to translate clinical data stored in the hospitals in data with a standard format. Ease-of-use and data security and integrity were the main design principles. Keywords—Electronic Health Record (EHR); Health Level Seven (HL7); HL7-CDA (Clinical Document Architecture of Health Level Seven).
I. INTRODUCTION The “Mattoni” of NSIS require that organization in charge of take care (hospital, laboratory) allow to put together all the information about the health course of the citizen in a digital way. The goal of “Progetto Mattoni” [1] is the creation of a common language among central administration and regions. This language is born to allow data interchange from Italian National Sanitary System. “The balance of this project seems to be positive”- said the General manager of Informative System of the Health Ministry, Walter Bergamaschi– “in fact Country and region have demonstrated of being able to communicate; attended results are reached”. The classification of health structure is changed, “glossary of name” are defined for the performances and the residential and semiresidential structures, of domiciliary or collective sanitary assistance. Classification systems that required to be reviewed, was updated; necessary informative contents are defined for being able to monitor the distribution of the Essential Levels of Assistance (first-aid, pharmaceutics, participations of prevention, characteristics of the reference hospitals); methodologies for the measures of delicate phenomena have been shared, for example for the waiting list, the outcome, the appropriateness, the minimum standard of quality and quantity, the costs of the sanitary companies and hospitals worker. “Mattone” had following
the following activity lines: the development of useful activities for the diffusion of the Electronic Health Record which, for example, the characterization of common modalities for the management of the registry offices; optimization of informative flow about the deaths registration and the definition of a reference frame for the Electronic Health Record development, preserving decisional autonomy on the priorities. “Mattone Patient file” has produced a series of very meaningful outputs that have tried to rationalize and to define a determining approach to the creation of the Electronic Health Record. “Conto Corrente Salute” (CCS) [2] is one the first responses to the need of “Progetto Mattoni”. CCS is a project contained by the “E-health Liguria – plan of the health electronic” (deliberated in 2006). This plan includes the priority actions of the Region, the development of standard and the sharing of good practical in order to facilitate the clinical exchange of information. ASL4 is a local health authority in Liguria that is interested to the CCS, an instrument for the realization of the Electronic Health Record. CCS is sort of “bank account” in which the authorized sanitary operators deposit and consult the citizen’s health data, with the full respect of the privacy normative. The patient can choose which documents collect on his own “bank account” and from which health structures. The citizen and also the health operators can consult recorded data (on a national level, public or private), in order to facilitate the exchange of the information among interested persons. CCS don’t have a standard reference language, so it use HL7 standard [3] [4] for exchange, management and integration of data. Health Level Seven is a non-profit organization accredited by the American National Standards Institute (ANSI) [5]. HL7 covers the interface requirements of an entire healthcare organization, i.e. between installed hospital and departmental information systems; it does not necessarily cover cross-institutional communication. Standard HL7-CDA [6] [7] (Clinical Document Architecture of Health Level 7) is an instrument used to import and to export structured clinical data from and towards the existing applications, in authenticated and signed documents; the purpose is the data exchange. CDA document can contain texts, images, sounds and other multimedia content. The CDA requirement for human readability guarantees that a receiver of a CDA document can algorithmically display the
O. Dössel and W.C. Schlegel (Eds.): WC 2009, IFMBE Proceedings 25/V, pp. 222–225, 2009. www.springerlink.com
Implementation of a Standard Service of Repository for Cardiological Unit
clinical content of the note on a standard Web browser. The goals of the CDA are: to give priority to delivery of patient care; to support exchange of human-readable documents between users, including those with different levels of technical sophistication; to promote longevity of all information encoded according to this architecture; to enable a wide range of post-exchange processing applications; to be compatible with a wide range of document creation applications; to promote exchange that is independent of the underlying transfer or storage mechanism; to prepare the design reasonably quickly; enable policy-makers to control their own information requirements without extension to this specification. A number of design principles follow from consideration of the above goals. The architecture must be compatible with XML (“eXtensible Mark-up Language” that is an important document structure standard for electronic data exchange in the medical field in different other settings) [8], with the HL7 RIM and with representations of clinical information arising from other HL7 committees. Technical barriers to the use of this architecture should be minimized. Then the architecture specifies the representation of instances required for exchange and imposes minimal constraints or requirements on document structure and content required for exchange finally the architecture must be scalable to accommodate fine-grained mark up such as highly structured text and coded data. CDA documents must be human readable using widely available and commonly deployed XML aware browsers and print drivers and a generic CDA style sheet written in a standard style sheet language. But a substantial analysis effort is necessary to interface a consolidated and proprietary informative system in order to suggest effective transition strategy to exhibit the data.
II. MATERIALS AND METHODS The schema in Fig. 1 illustrates the tables of the ASL4 database with the respective relations. It is a star schema with the central table named GC_CARTELLE. GC_CARTELLE is linked to SM_AMMISSIONE, SM_DIMISSIONE and SM_DATI_LETTERA_DIM through the external key ID_CARTELLA, while it is linked to the other tables through the external key ID_CARTELLA and PROGRESSIVO. The tables SM_PRESTAZIONI1 e SM_DETT_LETTERA_DIM are linked respectively to SM_ACCESSI1 e SM_DATI_LETTERA_DIM. The table SM_PRESTAZIONI1 has an external key ID_CARTELLA and PROGRESSIVO, while the table SM_DETT_LETTERA_DIM has only the external key ID_CARTELLA. The difference among the external keys is due to the type of cards, that is the cards linked to GC_CARTELLE only
223
through ID_CARTELLA are the ones that have a singular occurrence meaning that on a clinical folder there is only a card of this type.
Fig. 1 Illustration of ASL4 database Otherwise cards connected through ID_CARTELLA and PROGRESSIVO are the ones that have multiple occurrences because on a clinical folder there are more cards of this type. An further exception is the view GC_ESAMI_RX that is connected to the GC_CARTELLE through the field COD_ANAGRAFE (unique identifier of the ASL customer in Oasis4 [9]). A. General Description of Major Components of a CDA Document A CDA document is wrapped by the element, and contains a header. The header lies between the and the elements, and identifies and classifies the document and provides information on authentication, the encounter, the patient, and the involved providers. The body contains the clinical report, and can be either an unstructured blob, or can contain structured markup material. A CDA document section is wrapped by the
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 element within the element, and must contain the human readable content to be rendered. CDA entries can
IFMBE Proceedings Vol. 25
224
S. De Faveri et al.
nest themselves and they can reference external objects. CDA external references always occur within the context of a CDA entry. External references refer to content that exists outside this CDA document - such as some other image, some other procedure, or some other observation (which is wrapped by the element). Externally referenced material is not covered by the authentication of the document referencing it.
III. RESULTS The goal of this work is to map every attribute of the ASL tables in the equivalents attributes in standard HL7 but the standardization of a DB so extensive like the ASL4 one, require a lot of space and time so, here we will focus only on table named GC_CARTELLE (Fig.2). We want to make a coding as much general as possible in the way to render it more applicable and so we must analyze some R-MIM like: COCT_RM010000- A_Encounter R-MIM (Encounter
An example of results obtained is the attribute DATA_AMMISSIONE (that belong to the table GC_CARTELLE): it defines day, month, year and hour of patient admission. Code identified the type of examination (admission, department etc) and it is a CD type. From code we can set ActEncounterCode and then ActMedicalServiceCode until to set CARD code that is used to specify the field of interest, in this case it is the cardiological one; status Code is used to distinguish a closed examination from an ongoing one; it is a CS type and from this attribute we can set the value of ActStatus that could be: aborted, cancelled, active, new, etc.; effectiveTime identified a time interval: from the begin of the examination (admission, registration, arrival of the patient) until the patient discharge. The final data is set equal to the assumed time of conclusion if the examination isn’t already finished. EffectiveTime is an Act element, it is IVL type; AdmissionReferralSource is used to assign a category to the place type or to the responsible organization of the patient immediately before his admission, but it gives also detailed information about the place from where the patient could come previously, this is possible thanks to the "transportedBy act relationship” attribute. AdmissionReferralSource is an CE type element from it we can set EncounterReferralSource. Encounter.code = CARD (the dictionary from which derived the code is A:ActMedicalServiceCode it serves to say that it is a cardiological unit). Encounter.statusCode = new (the dictionary from which derived the code is S:ActStatusNormal it serves to indicate that the examination is beginning). Encounter.admissionReferrarlSourceCode serves to supply information about who has sent the patient in the unit. Encounter.effectiveTime. And if it is necessary, through Encounter.admitter.(…) command, it is possible to set also some information inherent to who has admitted the patient.
IV. DISCUSSION
Fig. 2 Illustration of a table of ASL4 database CMET is used for the identification of a specified examination of the patient); A_ObservationGeneral universal (COCT_RM120500UV) is a general observation that represents the fact that the General Events DMIM could also be useful for the representation of a non specialized variety of observation; finally we used more than the other Medical Records Domain which contained methods for the messages exchange, for the easier management of clinical folder and to render its compilation more easy.
In this wok we are involved in the mapping of each attribute of ASL4 cardiological tables. Some authors like Marcheschi P., Mazzarisi A., Dalmiani S., Benassi A. are interested at the same concept. They wrote a paper [10] in 2004 in which they exposed that different standards are used for treatment of clinical information, especially in cardiology but also in general in medicine. So, they aimed to integrate data coming from different sources and, to reach this goal, they used HL7-CDA. Moreover in agreement with us Ingeborg Schramm and Volker Weber in their article [11] said that to meet the requirements of “Integrated Care”, it is a basic need to share information. For this reason, Electronic Health Record (EHR) is a core part of a hospital information system, as
IFMBE Proceedings Vol. 25
Implementation of a Standard Service of Repository for Cardiological Unit
well as a service on duty of the patient to improve the treatment of patients. This goal cannot be reached since nobody is able or willing to switch off traditional systems.
V. CONCLUSIONS The HL7 standard that have the property of applicability and scalability can be used also in smaller reality but they want to maintain a high quality standard in the care of the patient, assuring to it also a wide possibility of interoperability with systems of care of greater dimensions and with more complex internal organization. HL7 is central for the patient who can see all health information related to him, but also the sharing of the clinical folder and the exchange of data through various units are very important for general health politic management. Obviously some prerequisites are fundamental like the willingness of the medical staff to write some processes and diagnostic therapies, using fixed code, at least in a local level. In the future it is expected that we shall use Web Services and client to make this system more approachable from everyone. So we could create a simpler interface that allow medical operator to not discourage them and force them to return to the old but efficient instruments. The aim is to create interfaces to make operators able to fill different fields with simple terms that could be translated using vocabulary in semantic relations even if it probably needed considerable efforts. If systems like this will be in common use patient but also National Sanitary System will take advantage, because it could access a great number of real data that could be easier elaborated in the respecting the rules of the privacy. So, that the availability of these data, epidemiological and comparative studies will be done.
225
ACKNOWLEDGMENT Thanks to dr. Silvia Bertirotti from Information Technology Department of ASL 4, Chiavari, Genoa, Italy for her suggestions on data structure.
REFERENCES 1.
Progetto Mattoni at http://www.nsis.ministerosalute.it/mattoni /paginaMenuMattoni.jsp 2. Conto Corrente Salute at http://www.forumpa.it/forumpa2006 /salute/cdrom/home/progetto/135.html 3. C.J. McDonald (1997) The barriers to electronic medical record systems and how to overcome them, J. Am. Med. Inform. Assoc. 3, pp. 213–221. 4. Health Level Seven Inc. HL7 Standards at www.hl7.org. 5. American National Standards Institute at http://www.ansi.org 6. R.H. Dolin, L. Alschuler, C. Beebe et al (2001) The HL7 clinical document architecture, J. Am. Med. Inform. Assoc. 6, pp. 552–569. 7. HL7 Standard “Clinical Document Architecture (CDA)” at http://www.hl7.org 8. W3C at http://www.w3.org/XML/ 9. Oasis4 at http://www.asl4.liguria.it/ovinternet/Resource/ICT /numeri_OASIS4.pdf 10. Marcheschi P, Mazzarisi A, Dalmiani S et al (2004) HL7 clinical document architecture to share cardiological images and structured data in next generation infrastructure. Computers in Cardiology: 617–620 DOI 10.1109/CIC.2004.1443014 11. Ingeborg Schramma, Volker Weber (2001) Incremental EHR introduction considering the situation in health care and the current standards under development. Computer Assisted Radiology and Surgery 1230: 889-894
Corresponding Author: Institute: Street: City: Country: Email
IFMBE Proceedings Vol. 25
Mauro Giacomini DIST – University of Genova Via All’Opera Pia 13 16145 Genova Italy [email protected] 