The health information systems interoperability framework (CI-SIS)
Référentiels d’intéropérabilité | 05 Jul 2010
ScopeThe health information systems interoperability framework, known as the CI-SIS, aims to meet two of ASIP Santé’s objectives:
- To define, promote and approve a Reference Frameworks Repository (RFR) to aid the interoperability, security and usage of health information and telehealth systems
- To develop shared information systems for the health and medico-social sector in order to improve the coordination and quality of care (including telemedicine), disease prevention and health monitoring.
The interoperability framework specifies the standards to be used when data is shared between health information systems, and how these should be implemented in order to allow secure interoperability between systems.
A system which initiates sharing transactions (storing, searching for and retrieving content) or exchange transactions (sending content) is called an initiating system. The system to which it sends the data is known as the target system.
Software for healthcare professionals (large practices/institutions) – hospital information system
Software for healthcare professionals (independent practices)
Health professional’s workstation
OrganizationThe CI-SIS is a modular, continuously evolving set of specifications. Each module consists of three layers:
Content: semantics, syntax and format of the shared or exchanged data
Service: interoperable services and the rules for using them
Transport: the protocols used to connect and send information
Each module contains the same set of security specifications.
CDA header mapping
Imaging object references
Minimal structuring of health documents
CDA content models
Biology test reports
Shared folder management
Health professionals access authorization matrix
Health document sharing
Health document exchange
Synchronous thick client (sharing)
Synchronous thin client (sharing)
Asynchronous (sharing + exchange)
v0.1.0 module approved 2/10/09
Module added by v0.1.1
Module for later version
Version 0.1.1, published on 25 February 2010, contains three content modules, two service modules and one transport module. Additions will continue to be made to the RFR during the dialogue phase with the host of the first version of the electronic health record, called DMP 1, and this will be followed by a further industry consultation phase culminating in version 1.0.0, which will be published during the third quarter of 2010.
The interoperability framework will encourage health information systems to evolve by gradually imposing structure on the content. The minimum level of structure required in the first version will require little additional work for systems already involved in the sharing and exchange projects. In addition, the metadata specifications for the service module will place the main burden on health professionals’ software, while reducing the impact on target systems.
The content layerPermanent clinical content
Information will be shared and exchanged between health information systems in the form of electronic documents, which provide the health professional or patient with comprehensive, contextual, authenticated, permanent, attributable and manageable information. They can also provide the raw data from which this information derives, coded and structured for the health information systems’ databases.
The selected standard is CDA R2, which specifies a clinical document XML syntax comprising an inseparable header and body. The header identifies and qualifies the document, references the documented patient contacts, and identifies the participants in these contacts and in the creation of the document. Three key participants are identified: the author; the person responsible for the document, who is also its legal signatory (using an electronic signature and a CPS root certificate); and the issuing organization, which is responsible for its life cycle.
The body of the document is structured to varying degrees depending on the nature of the content. An unstructured body includes a PDF, an illustration (JPEG or TIFF), or raw text.
Medical imagesMedical images remain in the picture archiving and communications system (PACS) and are made accessible to digital imaging and communications in medicine (DICOM) applications via imaging reference documents published in shared folders.
Service moduleElectronic health documents are shared or exchanged in submission batches. Each document and batch has a set of metadata to facilitate indexation, storage and searching. The metadata complies with IHE XDS-b and XDM profiles. The majority of the metadata in a document derives directly from its CDA header, while most of the metadata representing participating health professionals comes from the health professional card (CPS) or the shared register of healthcare professionals (RPPS).
The main item of metadata representing the patient is their national health identifier (INS), which is compulsory for sharing and communication.
Among the other most obvious metadata used to facilitate searching are patient contacts connected with the document, the contact operating framework, pathology diagnosis, document type, author’s profession/specialty, time window, and the health professional or establishment issuing it.
The metadata are also used by the host of the shared health information system to control document access rights. The metadata used for this purpose are the document confidentiality level and document type, linked to the profession of the person requesting the document.
As well as sharing and exchange services, a shared patient file management module allows a patient identifier to be obtained, and will eventually also include file opening and closing services.
Transport layerThis layer offers a thick client synchronous transmission module in accordance with annex V of the IHE ITI technical framework, specifying standards used for the service call and response and the service definition. Any flow emanating from an initiating system must include a formal identification and authentication vector in accordance with the IHE XUA profile, stating the user's identity, confirmation of the patient’s consent and the information required by the target system to determine authorizations. The vector is signed using a server certificate (in the case of a hospital professional) or the user’s CPS certificate.
This layer will soon be expanded to include a web browser-type thin client transport module and a transport module for S/MIME messaging clients.
ConsultationVersion 0.1.0 was published on 2 October 2009 and approved by industry representatives. Version 0.1.1 was published on 25 February 2010 and added new content to this set of stable specifications, including biology reports and a service module. Comments entered on the form published in the deliverables on the ASIP Santé website are still being accepted at email@example.com, and will be taken into account before drawing up the next version, which will again be subject to consultation.