Evidence map›Paper›PMID 24734138›Full record

ArticleApplied clinical informatics2014

Design and multicentric implementation of a generic software architecture for patient recruitment systems re-using existing HIS tools and routine patient data.

B Trinczek, F Köpcke, T Leusch, R W Majeed, B Schreiweis, J Wenk, B Bergh, C Ohmann, R Röhrig, H U Prokosch and 1 more

Abstract read
In one paragraph

Article in Applied clinical informatics, 2014. The graph could read no effect estimate from its abstract, so it casts no vote on the map. Cited by 12 papers, 1 of them a synthesis that pooled it.

0numbers the graph read from it
0cells of the map it votes in
12citing papers in PubMed, 1 pooled it
–field-weighted citation impact
1 · What the graph read from it

What it found

Each row is one number read from the abstract, on the scale the paper reported it, with its interval. Left of the dashed line favours the treatment, right favours the comparator. Under each row is the sentence it came from. New to these charts? A ten-minute tutorial.

The abstract states no effect estimate the extractor could read, or names no intervention and outcome on the map, so this paper lights no cell and moves no belief. It is still indexed, cited and linked below.

2 · The registry

The trial behind it

Trials whose registry record cites this paper, or whose number appears in the abstract. A trial that started after this paper was published is citing it as background, not reporting it.

Neither the registry nor the abstract names a trial number. If this is a trial report, that itself is worth knowing.

3 · Its place in the literature

Who cites it

12 citing papers in PubMed, 1 synthesis or guideline pooled it.

  1. Pooled it
  2. Article
  3. Article
  4. Article
  5. Article
  6. Article
  7. Article
  8. Article
  9. Article
  10. MAGIC: once upon a time in consent management-a FHIRJournal of translational medicine · 2018
    Article
  11. Article
  12. Article
4 · The record

Corrections and comments

PubMed lists nothing against this paper. Absence here is not a guarantee, only a check that was made.

5 · Who and what money

Authors and funding

11 authors.

B TrinczekInstitute of Medical Informatics, University of Münster , Germany.
F KöpckeChair of Medical Informatics, Friedrich-Alexander-University Erlangen-Nuremberg , Germany.
T LeuschDepartment of Information- and Communication-Technology, Düsseldorf University Hospital , Germany.
R W MajeedDepartment of Anesthesia and Intensive Care Medicine, Justus-Liebig University Gießen , Germany.
B SchreiweisCenter for Information Technology and Medical Engineering, Heidelberg University Hospital , Germany.
J WenkCoordination Centre for Clinical Trials, Faculty of Medicine, Heinrich Heine University Düsseldorf , Germany.
B BerghCenter for Information Technology and Medical Engineering, Heidelberg University Hospital , Germany.
C OhmannCoordination Centre for Clinical Trials, Faculty of Medicine, Heinrich Heine University Düsseldorf , Germany.
R RöhrigDepartment of Anesthesia and Intensive Care Medicine, Justus-Liebig University Gießen , Germany.
H U ProkoschChair of Medical Informatics, Friedrich-Alexander-University Erlangen-Nuremberg , Germany.
M DugasInstitute of Medical Informatics, University of Münster , Germany.

Funding

No grant is acknowledged in the PubMed record.

6 · The paper itself

Abstract

objective(1) To define features and data items of a Patient Recruitment System (PRS); (2) to design a generic software architecture of such a system covering the requirements; (3) to identify implementation options available within different Hospital Information System (HIS) environments; (4) to implement five PRS following the architecture and utilizing the implementation options as proof of concept.

methodsExisting PRS were reviewed and interviews with users and developers conducted. All reported PRS features were collected and prioritized according to their published success and user's request. Common feature sets were combined into software modules of a generic software architecture. Data items to process and transfer were identified for each of the modules. Each site collected implementation options available within their respective HIS environment for each module, provided a prototypical implementation based on available implementation possibilities and supported the patient recruitment of a clinical trial as a proof of concept.

results24 commonly reported and requested features of a PRS were identified, 13 of them prioritized as being mandatory. A UML version 2 based software architecture containing 5 software modules covering these features was developed. 13 data item groups processed by the modules, thus required to be available electronically, have been identified. Several implementation options could be identified for each module, most of them being available at multiple sites. Utilizing available tools, a PRS could be implemented in each of the five participating German university hospitals.

conclusionA set of required features and data items of a PRS has been described for the first time. The software architecture covers all features in a clear, well-defined way. The variety of implementation options and the prototypes show that it is possible to implement the given architecture in different HIS environments, thus enabling more sites to successfully support patient recruitment in clinical trials.

Indexed as

Hospital Information SystemsPatient SelectionSoftwareDatabases as TopicGermanyHealth Plan ImplementationHumansClinical trials as topichospital information systemspatient identification systemspatient selectionsoftware architecture

Identifiers

PMID24734138
PMCPMC3974260

What OpenQuestion holds

Textmetadata
Read underepoch 390

Registered trials

None linked

Read under generation 80e0d062 · epoch 390. Bibliography from PubMed, PubMed Central and OpenAlex; grants from NIH RePORTER; trial links from ClinicalTrials.gov; estimates, votes and beliefs from the OpenQuestion graph.