There are a number of steps involved here:
In terms of evaluating data readiness and data updating, the following key points are relevant;
De-identified EHR data needs to be copied from your local EHR system or your local EHR data warehouse into the local EHR4CR Clinical Data Warehouse (CDW) by means of process called “Extract Transform and Load (ETL)”. Because your local EHR data applies local language and codes, a mapping to the central EHR4CR terminology in English is required. This can be thought of as converting your local data in to a “Common Vocabulary” on which the system and all its partners can operate. The amount of mapping work and other setup activities will depend on your local EHR infrastructure. If you already have a well-structured local EHR data warehouse (which is also very useful for other clinical and administrative purposes), then the setup process will be a lot simpler. It is strongly recommended to involve a local EHR technical specialist. EHR4CR service providers will also provide IT support to setup your local EHR4CR endpoint.
The Protocol Feasibility Service includes an audit trail that will be able to provide information on the creation and modification of the protocol feasibility query.
The EHR4CR platform will optimize protocol feasibility assessment, enhance and accelerate patient identification and recruitment and facilitate study conduct and Serious Adverse Event(SAE) reporting.
This will lead to revenues which will be proportional to:
The business case for this is evident from the following:
Early adopters have the opportunity to build commercial benchmarks and establish themselves as ‘Clinical Research Centers of Excellence’.
The clinical investigator fees are negotiated and managed between funders of clinical studies and investigators. The Data Providers (DPs) will be invited to connect to the EHR4CR platform in exchange for a small yearly subscription which will enable them to participate in the EHR4CR network and to charge data access fees for contributing data to the platform. In this way any effort to put in place and maintain participation in EHR4CR would be covered through data provision revenues via the EHR4CR Service Provider. Connection to the platform will enable DPs to participate in more clinical trials and to generate more revenues from its clinical research activities.
In order to stimulate early participation and to build the market, some Service Providers (SP) may include financial incentives for early adopters (e.g. potential discounts, rebates, service bundling etc). It will be discretionary to each SP as to how it performs this incentivisation.
The yearly subscription that each Data Provider (DP) will pay to the Service Provider (SP) to connect with the EHR4CR platform will include full technical guidance and support (e.g.help desk, IT support etc). Note: It is anticipated that the data access fees that DPs would charge for contributing EHR data to the platform would far exceed the minimal yearly subscription to the SP for connecting to the EHR4CR platform.
The intent is for Service Providers (SPs) to ultimately provide end-to-end EHR4CR solutions to:
(a) Pharma/CROs for using EHR4CR clinical research services
(b) Data Providers (DPs) for contributing EHR health data to the platform
The main contractual agreements to be set up in this new environment would therefore be via the Service Providers.
No. Institutions must formally sign up with EHR4CR before being granted access. This includes Legal and Code of Conduct agreements. There are robust 'role-based access controls' (RBAC) which determine what institutions can take part, and what facilities/permissions they can grant to their staff. For example, at Research Centres, only Study Managers can create Studies and assign users to run queries under that Study, so even with a Research Centre staff are restricted as to what queries they can submit.Each user has an individually assigned password with assigned RBAC. Audit facilities within the platform allow activity to be assigned to individual users based on their password.
There is no reason for a National Institution not to get involved. Obviously this involvement would need to be negotiated.
Identifiable 'personal data' (whether sensitive or not!) never leaves the Data Provider site. Maintaining patient privacy and confidentiality is a key feature of the EHR4CR technology and processes. A large number of system security features, encryption technologies and governance processes ensure that health data can be re-used in a trustworthy way. Until a patient has consented to participate in a clinical trial, only aggregate data is extracted from de-identified datasets at each Data Provider (DP) site. Fuzzing logic ensures that low number counts never leave the DP site. The aggregate numbers consolidated with counts from other sites before being presented by the platform to the research centre which generated the query.
Firstly, the data in the Clinical Data Warehouse is limited to only relevant data elements required for clinical research, it is segregated from the EHR data (a one way process), stripped of indentifiers (e.g. contact details) and pseudonymised.
Secondly, each Study has pre-defined parameters within which queries may be submitted, which restricts the opportunity for 'jigsaw' attacks.
Thirdly, each data-provider can set the level of restriction on the aggregated data where low cell-counts might occur â€“ this will limit the scope for 'jigsaw' attacks;
Fourthly, both research centres and data-providers can check audit logs to analyse any suspicious activites and report them;
And finally, there is a high level administration control facility, whereby each data-provider can choose whether or not to authorise queries on a case-by-case basis. This facility will quickly reveal suspicious activity though at the disadvantage of limiting the benefits of a rapid response to queries.
Code of conduct rules exist at both individual and organisation level and penalties for improper use are also in place.
The precise legal basis may vary across EU member states to reflect the different legal and health systems. However all European countries comply with European data protection legislation, and EHR4CR has adopted an approach that meets the highest privacy protection standards across European countries. Fundamentally, the 'personal data' used within the Clinical Data Warehouse is interrogated for 'historic, statistical, and scientific purposes' only. The data within the Clinical Data Warehouse is de-identified and as such doesnt constitute 'personal data' It is only the resultant aggregated de-identifdied information that is being shared.
In some legal juristictions, there may be established options for patients to indicate personal preferences such as whether they do or do not want to be approached to participate in studies or whether their data should or should not be used for such purposes. Settings would be applied when 'loading' the Clinical Data Warehouse to ensure that these individual preferences are respected and complied with.
First, the Research Centre must have 'Published' their intent to perform a Study, the Recruitment Centre must have 'Subscribed' to this and have been accepted as participating by the Research Centre.
Only treating clinicians within that hospital can access a patient's personal details within a Recruitment Centre.
Once a patient has been identified and has consented as a potential study participant, the 'treating clinician' would pass on their details to the Principal Investigator (PI). Patient data would only be passed to the Research Centre after a patient has accepted the inivitation and has consented to participate in the study.
All institutions involved will be required by their contracts of operation to perform audit checks on their users to ensure that they are using the system appropriately. Each institution is also subject to external audit by regulatory authorities or for clinical governance requirements within their own country.
Further, the newly created EHR4CR institute ('The European Institute for Innovation through Health Data') will verify that the institutions are performing their audit checks and publishing quarterly status reports.
Any problems discovered will be escalated through the new EHR4CR Institute as well as to national Data Protection Authorities (as will be required under the new draft Data Protection Regulation). Where relevant, individuals would be informed of any breaches of their privacy. It is important to reiterate that no 'personal data' leaves the data-provider without the patients' express consent.
There are two scenarios of interest here namely:
As a Data Provider, this is very much your own choice and will depend on existing resources and procedures, and perceived level of risk. A hospital that conducts clinical research will already have a number of audit and governance processes in place to handle the feasibility, recruitment and trial conduct phases. EHR4CR will introduce only a small number of additional information flows that will require additional governance. This will mostly be to approve the initial acceptance and set up. Once operational the ongoing monitoring processes should take no more than a few hours per month to review audit logs and consult with users
Audit reports can be requested through the Governing Institute, the Service Provider and/or the local Data Provider. Each point in the chain will be able to provide an evidence trail of data usage.
For FT queries, the following is recorded;
Note: The actual results of the query are not retained by the EHR4CR tools, though such information may be retained with in actual Clinical Data Warehouse (CDW) used or ancillary systems.
In the process that is being developed and piloted as part of the project, the investigator selects the data instances that should be transferred into the eCRF and this data will be copied across with appropriate metadata. This step will initiate the audit trail within the EDC system. The source of the data will be captured.
A certification/accreditation process operated by the new European Institute for Innovation in Healthcare Data will ensure that systems within the network conform with pre-defined compliance criteria and will include checks that systems have been developed and implemented according to leading software development practices.
Accreditation is the confirmed, recognized (technical) competence of an organisation or individual. In the case of EHR4CR, the hospitals will act as a data provider for specific services which are based on a conformity assessment.
Certification is a confirmation that pre-defined requirements/standards are fulfilled. The certification is a written assurance ('the certificate') issued by an independent, external body, in this case the European Institute for Innovation Through Health Data.
Certification will act as the formal 'stamp of approval' or readiness to operate in the EHR4CR network. It Certifies the organisation as being trustworthy in the use of health data (in compliance with the pre-defined requirements and standards). The exact and final operational mechanisms are presently being defined.
The new European Institute for Innovation Through Health Data will be a dedicated legal entity and will operate on directions provided by a General Assembly , the Executive Board and the leadership team (the president, the vice president[s] and the treasurer). The legal framework will describe operational aspects at different levels which consist of the statutes, by-laws and documents describing various types and aspects of operations.The Institute will support initiatives in the general areas of eHealth Innovation and Knowledge Discovery by providing a formal operational space from which institutes can operate.
The European Institute for Innovation through Health Data will be officially registered byearly 2015. Operational readiness of the Institute, including the provisioning of oversight, is also planned for early 2015.
In technical terms, there are several options available to you. For example the locally authorised system administrator can;
On a broader basis you can do the following;