ICT 269978
Integrated Project of the 7th Framework Programme
COOPERATION, THEME 3 Information & Communication Technologies ICT-2009.5.3, Virtual Physiological Human
Work Package: WP5 Patient-Centred Multiscale Computational Workflows
Deliverable: D5.1 Patient Avatar Defined for Flagship Workflows
Version: 1.2 Date: 30-Nov-11
FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
This page is intentionally blank
Page 2 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
DOCUMENT INFORMATION
IST Project Num FP7 – ICT - 269978 Acronym VPH-Share Full title Virtual Physiological Human: Sharing for Healthcare – A Research Environment Project URL http://www.vphshare.org EU Project officer Joël Bacquet
Work package Number 5 Title Patient-Centred Multiscale Computational Workflows Deliverable Number 5.1 Title Patient Avatar Defined for Flagship Workflows
Date of delivery Contractual 30-Nov-11 Actual 30-Nov-11
Status Version 1.2 Final Nature Prototype Report Dissemination Other Dissemination Public (PU) Restricted to other Programme Participants (PP) Level Consortium (CO) Restricted to specified group (RE)
Authors (Partner) Susheel Varma (USFD), Enrico Schileo (IOR), Maria-Cruz Villa (UPF), Pablo Lamata (KCL), Breanndan Ó Nualláin (UvA) Responsible Rod Hose Email [email protected] Author Partner USFD Phone +44 114 271 2313
Abstract (for This report considers patient-centred multiscale computational workflows and the dissemination) digital patient avatar concept in particular. It begins with a useful overview of electronic care/health record technologies and outlines the implications for the patient avatar in VPH-Share. Four flagship workflows are then described, each providing details of the processing steps and involved. A survey of the clinical data required and the specific clinical data required by each step is detailed. A patient Avatar is then defined for each workflow.
Keywords Patient avatar, electronic health records, scientific workflow, workflow information model
The information in this document is provided as is and no guarantee or warranty is given that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability. Its owner is not liable for damages resulting from the use of erroneous or incomplete confidential information.
Page 3 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Version Log Issue Date Version Author Change 16-Nov-11 0v6 Susheel Varma Draft report delivered for internal review 23-Nov-11 0v8 Susheel Varma Internal review comments and compiled patient avatars incorporated 30-Nov-11 1v0 Susheel Varma Final proof read before publication 30-Nov-11 1v1 PMO Proof read 30-Nov-11 1v2 PMO Submission version
Page 4 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Contents
EXECUTIVE SUMMARY 7
1 INTRODUCTION 9
2 BACKGROUND 11
3 ELECTRONIC HEALTH RECORD STANDARDS 13
4 PATIENT AVATARS 24
5 WORKFLOW INFORMATION MODELS 32
6 DISCUSSION & OUTSTANDING CHALLENGES 75
7 CONCLUSIONS 76
8 REFERENCES 77
LIST OF KEY WORDS/ABBREVIATIONS 81
ANNEX 1: @NEURIST WORKFLOW SERVICES 83
ANNEX 2: @NEURIST WORKFLOW SCHEMATIC DIAGRAM 85
ANNEX 3: VIROLAB LISTINGS 86
ANNEX 4: @NEURIST COMMON REFERENCE INFORMATION MODEL 89
ANNEX 5: @NEURIST PATIENT AVATAR 90
ANNEX 6: EUHEART PATIENT AVATAR 111
ANNEX 7: VIROLAB PATIENT AVATAR 141
ANNEX 8: VPHOP PATIENT AVATAR 157
Page 5 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
LIST OF FIGURES
Figure 1: Pre-Electronic Health Records [5] ...... 13
Figure 2: Electronic Health Record [5] ...... 14
Figure 3: Generic Model: relationship between care cycle phase and disease course [8] ...... 15
Figure 4: Dual Model Approach: Blood Pressure Example ...... 17
Figure 5: Archetype Design Process and Repository [12] ...... 18
Figure 6: Archetype Dissemination [12]...... 20
Figure 7: Computational Biomechanics Workflow: Patient to Risk Assessment [15] ...... 26
Figure 8: The Problem of Standard Proliferation [16] ...... 28
Figure 9: Patient Avatar Interoperability ...... 29
Figure 10: Schematic Relationship Between HER Standards [17] ...... 29
Figure 11: Complex information processing workflow (@neurIST example) ...... 32
Figure 12: Overview of the Pressure Estimation Workflow ...... 48
Figure 13: Velomap Tool, showing selected processing options [38] ...... 50
Figure 14: Spatio-temporal map of pressure differences ...... 53
Figure 15: Twilight visualisation tool showing clusters of HIV patients ...... 58
Figure 16: Simplified VPHOP workflow (Clinical Perspective) ...... 65
Figure 17: Simplified VPHOP workflow (modelling perspective) ...... 66
Figure 18: VPHOP workflow (architectural prespective) ...... 68
LIST OF TABLES
Table 1: Archetype Design Patterns ...... 19
Table 2: Data resources available to VPH-Share (subject to licence and governance) ...... 28
Page 6 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
EXECUTIVE SUMMARY
This report considers patient-centred multiscale computational workflows, the significance of the digital patient avatar concept, and the possible implementation of such an avatar in the exemplar workflows within the VPH-Share project.
Having established the background to the concept, the report continues with an overview of the various electronic care/health record (EHR) technologies and their core components. It also examines the standards that exist in the domain, their relationship to the requirements for a patient avatar, and the degree to which the two concepts are, or may become, intertwined. It then examines the evolving avatar concept itself, the ethical and legal constraints that should be considered, and the role for such data constructs within simulation workflows.
The four VPH-Share exemplar workflows are then described in detail, in each case examining the processing steps involved, the clinical and other data items that contribute to the workflow’s operation, and the consequences for implementation of a workflow-specific avatar to support the process. For each workflow, mechanisms for missing-data replacement are considered and specific ethical and legal issues are discussed.
Finally the report considers the general status of the avatar concept within medical simulations, and the remaining challenges that have been identified. In a series of significant and comprehensive annexes, the various aspects of workflow operation are illustrated, followed by a full avatar description for each exemplar workflow, presented within a structured hierarchical data construct.
Page 7 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
This page is intentionally blank
Page 8 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
1 INTRODUCTION
“We are only now beginning to acquire reliable material for welding together the sum total of all that is known into a whole; but on the other hand it has become next to impossible for a single mind to command more than a small specialised portion of it.”
~ Erwin Schrödinger – What is Life? (1944)
The acquisition of quantitative and high quality biological data over the last six decades has continued and Schrödinger’s insight still remains salient today. The first high-resolution mapping of the human anatomy performed by The Visible Human Project1 and the relentless advancement of computational and numerical techniques used across the VPH (Virtual Physiological Human) community and beyond, to educate and inform science stands further testament to Schrödinger’s vision.
VPH-Share is building an infostructure to facilitate the construction and management of VPH workflows, with focus on the three primary elements of such workflows, i.e. models, tools and data. The target user of this infostructure is the VPH researcher. The process is exemplified by four flagship workflows that together cover conceptually much of the breadth of current VPH research. Four major advances in VPH-Share are:
i) to develop and promote the concept of the patient avatar as the digital representation of all health-related data that is available for the individual, as the general basis for the construction of Virtual Physiological Human workflows; ii) to develop the representation of variation and uncertainty in our model descriptions, and for this we are extending the existing Mark-up languages, CellML and FieldML, most widely adopted by the community; iii) the construction of appropriate personalized physiological envelopes for our simulations, informed by patient data that might be found in the Electronic Health Record (EHR) or, possibly, from Personal Health Records (PHR); iv) the organisation and annotation of the clinical data in such a way as to be readily accessible and usable by the workflows.
This document has three primary purposes:
i) to describe the representation that VPH-Share will use for clinical data (the core of the patient avatar) and the conceptual process for the linking of these data to the concepts used by the workflows; ii) to describe in detail the operations performed in each of the four flagship workflows, and particularly to describe the inputs to and outputs from each of these operations iii) to list the concepts in the patient avatar for each workflow. This list, for each workflow, is the condensation of all information that might be recorded about the patient to a subset that is considered most likely to be relevant to that workflow, whether in terms of associations with specific workflow inputs, and thus likely to
1 https://www.nlm.nih.gov/research/visible/visible_human.html
Page 9 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
inform the construction of the simulation envelope, or in terms of establishment of associations with outputs that might assist the diagnostic or simulation process for future patients. This is not intended to be a final list, and we expect the avatar to evolve as the project progresses. We also expect that a single patient avatar will be constructed from the component parts associated with each workflow, and note already the overlap of several concepts common to more than one workflow.
The description of a concept in the avatar does not mean that these data are necessarily available to the researcher, or even to the clinician caring for the patient. Data might not have been collected, or there might be no permissions to share. A purpose of this document is to establish the first shortlist of what concepts in the avatar might be useful for specific workflows and to support the development of the VPH-Share infostructure. It is not a purpose to explore the clinical data collection process or the ethical or governance framework, although of course these are fundamental to the execution of workflows through the infostructure.
This document will serve as the basis for first exchanges between the workflows and the technical work packages, WP2, WP3 and WP4 of detailed information about the concepts that underpin the VPH patient avatar, as well as for consideration by the Clinical and Ethics Board (CEB) in their production of guidelines for legitimate exposure of these data. The next steps will be the actual implementation of the avatars for the specific workflows, their consolidation into a single avatar, the confirmation by the workflow leaders of the ethical and governance positions for each of the data items (or combinations of them, illuminated by the guidelines from the CEB), the mapping of the concepts in the avatar to the inputs and outputs of the workflows, and the first operation of the flagship workflows using the avatar as an underpinning source, and repository, of information.
Page 10 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
2 BACKGROUND
The Virtual Physiological Human (VPH) initiative began in 2005 primarily as a research initiative and since its inception, its focus according to the STEP Roadmap [1], has been the “creation of a framework of methods and technologies that, once established, will make it possible to investigate the human body as a whole”. The current evolutionary approach of integrating heterogeneous data, information and knowledge within the VPH is a radical approach that is envisaged to yield applications to specific clinical targets, but requires novel and innovative ICT and scientific approaches far beyond what the VPH has today.
The VPH is an extremely broad initiative, which has projects in virtually all aspects of biomedical research and clinical practice. On current estimates, there are over 100 research projects developing and applying VPH-related technology worldwide, each with clinical targets that go from the predictive models of cerebral aneurysms to the prevention of osteoporotic fractures in the elders. To provide an exhaustive coverage of all the numerous research activities is clearly impractical for a document such as this. Here we mention a few examples, which can give the impression of what VPH research has and can achieve. For a more detailed overview, see Miller [2].
The @neurIST project has developed an integrative approach that considered a uniquely diverse set of factors related to the rupture of a cerebral aneurysm [3]. The Living Human Digital Library Project has created the first multiscale data collection on the skeletal system in the world, and made it available to the research community through the Physiome Space data sharing service2. The VPHOP model was able to accurately predict the incidence in the Italian general population of osteoporotic fractures3. PredictAD used a combination of imaging and computer models by researchers to identify and quantify changes in brain that could be used to make early and more accurate diagnosis of the Alzheimer’s disease4.
Even though the VPH is still relatively young, there are already a few dedicated biological data repositories, mostly devoted to sharing of data, models5 and tools6:
PhysiomeSpace is a digital library service that enables sharing of large biomedical research data2. The CellML repository hosts a large number of physiological and pathological processes at the cellular or metabolic level5. The BioModel repository contains models of biomedical reactions and other significant process relevant for biological research.
2 http://www.physiomespace.com/ 3 http://www.vphop.eu/ 4 http://www.predictad.eu/ 5 http://www.cellml.org 6 http://toolkit.vph-noe.eu/
Page 11 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
The VPH Toolkit hosts a catalogue of software tools and services available for biomedical research6. The PhysioNet repository provides a large collection of physiological signals for research purposes7.
In this light, the multitude of research projects and the availability of free biomedical data, tools and services, across the length and breadth of the VPH community, could conceivably converge toward a common reference system for human biomedical data, information and knowledge, namely the Patient Avatar.
Within the context of the VPH, the Patient Avatar equates to a large catalogue of every item of data, information and knowledge on a patient or a collection of patients that can be shared securely, to allow it to be searched, browsed, interactively explored, for a broad range of reasons, including leisure, education, healthcare, etc.. In particular, with respect to scientific workflows, the possibility to find, retrieve, and reuse all of the data, information and knowledge that is available on patients and their physiological attributes could truly revolutionise the field, increasing exponentially the potential uses of VPH technology.
7 http://www.physionet.org/
Page 12 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
3 ELECTRONIC HEALTH RECORD STANDARDS
The idea of a Patient Avatar is not new; in fact it is not even revolutionary. The Electronic Health Records (EHRs) exist today in a similar vein, just as they had existed decades earlier. An electronic health record aims to be, a comprehensive record of clinical information about a patient in active or passive care. The first known medical record was developed by Hippocrates, in the fifth century B.C. and prescribed two goals [4]:
A medical record should accurately reflect the course of disease. A medical record should indicate the probable cause of disease.
Centuries later, these goals have changed only slightly, reflecting the use of technology to provide additional functionality, such as alerts and workflows. Some even completely avoid paper-based systems.
An electronic record may be created for each service a patient receives during care at a medical institution, such as laboratory, radiology, pharmacy. Some institutions also capture physiological signals, alerts, physician’s notes, etc.. Pre-EHR these records were never integrated, but remain in their captured silos, see Figure 1.
Figure 1: Pre-Electronic Health Records [5]
A clinician would have to manually open a series of applications to view a patient’s complete record, as each department may use different standards, vocabularies, user identification. An
Page 13 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
integrated view of all these systems provides the clinician with a unified view of the patient, even providing real-time alerts for lab or test results. It also allows the different departments to resolve vocabulary variations, through the use of structured vocabulary and nomenclature.
The Health Information Management Systems Society’s (HIMSS) defines EHRs as:
“The Electronic Health Record (EHR) is a longitudinal electronic record of patient health information generated by one or more encounters in any care delivery setting. Included in this information are patient demographics, progress notes, problems, medications, vital signs, past medical history, immunizations, laboratory data, and radiology reports. The EHR automates and streamlines the clinician's workflow. The EHR has the ability to generate a complete record of a clinical patient encounter, as well as supporting other care-related activities directly or indirectly via interface—including evidence-based decision support, quality management, and outcomes reporting.”
It is important to note that such a longitudinal EHR represents the collection and maintenance of all the information about an individual over a long period within an institution, such as a hospital or integrated delivery network. An EHR is not a longitudinal record of all care provided to the patient at multiple venues over time. However, longitudinal records may be kept in a nationwide or regional health information system by combining longitudinal records at multiple venues. The longitudinal relationship aspect of care delivered to wide spectrum of populations and individual patients is shown in Figure 2.
Figure 2: Electronic Health Record [5]
Page 14 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
The key components of an Electronic Health Record are:
Administrative System Components Laboratory System Components Pharmacy System Components Computerised Physician Order Entry Clinical Documentation
Detailed information regarding these components is beyond the scope of this document, however, it is important to bear these components in mind. The Clinical Documentation prescribes how the entire record is structured and accessed. Some of these have been standardised through a process of achieving consensus and approved by a recognised body that provides the various specifications and guidelines. The brief summary of the various structured standards based on multiple reviews of the industry healthcare record standards by Eirchelberg et al., Kalra and Schloeffel [5-7], is presented in the next few sections. Many vendors of medical equipment also integrate directly to this standard, which allow medical institutions more flexibility in choosing vendors; but as we will see this has resulted in proliferation of Electronic Health Record standards, each with their own focus. Medical institutions are still actively pursuing a transition to a universal standard across the globe.
Figure 3: Generic Model: relationship between care cycle phase and disease course [8]
As Kalra [6] explains, decades of cross-industry research have highlighted the clinical, ethical and technical challenges that need to be met to effect this transition. There is a vital need for interoperability standards to meet such challenging requirements to permit clinical computer systems to share health record data whilst preserving faithfully the clinical meaning and context of the individual authored contributions within it. Concerns about protecting the confidentiality of sensitive personal information must also be addressed if user confidence is to be maintained when EHRs are exposed to a wide community of individuals and organisations.
Page 15 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Good electronic health records are not just an aggregated collection of dispersed heterogeneous clinical data about individuals. Each entry signifies a formal authored contribution to a growing and evolving story, through which the authors are accountable for health care actions performed or not performed. At any point during the cycle of care, see Figure 3, of a patient, the health record must provide the information basis against which old findings are verified and new findings are interpreted; and hence its integrity, completeness and accessibility are of paramount importance [9].
Extensive investigations of user and enterprise requirements have taken place over many years to capture the health record information needs across primary, secondary and tertiary care, between professions and across countries. These requirements have been distilled and analysed by expert groups, internationally, in order to identify the essential information that must be accommodated within an EHR architecture to:
capture faithfully the original meaning intended by the author of a record entry or set of entries; provide a framework appropriate to the needs of professionals and enterprises to analyse and interpret EHRs on an individual or population basis; incorporate the necessary medico-legal constructs to support the safe and relevant communication of EHR entries between professionals working on different sites, whilst respecting the privacy wishes of individual patients.
Detailed reviews of this domain [10] have now been consolidated by ISO as an International Technical Specification, which provides a single point of reference for the core EHR requirements [7].
The communication of EHR information is complex because much of clinical meaning is derived not from individual data values themselves but from the way in which they are inter- linked together as compound clinical concepts, grouped under headings or problems or associated with preceding healthcare events during the act of data entry or data extraction. The medico-legal nature and accountability of health care delivery places additional requirements on the rigour with which health record entries are attributed, represented and managed. The way in which individual clinical statements are hierarchically nested within a record confers an important context for their interpretation. Aspects of certainty, severity and the absence of findings must be capable of rigorous and unambiguous representation [6].
Even with such longitudinal approaches of patient data collection, most medical interventions established in daily clinical practice, are based on a generic or holistic approach that follows guidelines or rules-of-thumb, typically based on epidemiological evidence from large clinical studies, and are not personalised for the patient.
Today, there is a widespread consensus that the best way to provide improved clinical care is by personalising the therapy to the individual (genetic or phenotypic) attributes and specifically targeted to biochemical processes specific to the disease.
The Patient Avatar aims to use one of the EHR standards as a vehicle to instigate a system that integrates and optimises all available information about a patient, and to extrapolate
Page 16 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
missing data and personalise predictions or simulations of relevant disease processes. It intends to be integrated as part of a framework of methods and technologies that will make it possible to describe the uniqueness of human physiology and pathology in an integrated and comprehensive way [11]. 3.1 Dual Model Approach Supporting large-scale sharing of health records, and their relevant contexts across distributed sites, requires a consistent and generalised approach that allows the user to precisely specify the desired part of the EHR document required. Such an approach needs to be able to cater to any specialty or profession whilst recognising that the information contained with the EHR will be diverse, complex and frequently updated to reflect the advances in medical science. To be specific, the EHR must support semantic interoperability, where the actual data may change due to the context, but the context (metadata) is specified accurately. An example of contextual specificity of a blood pressure measurement is described in context of the overall information model in Figure 4.
Figure 4: Dual Model Approach: Blood Pressure Example
3.1.1 Reference Information Model
A Reference Information Model is used to describe and represent generic properties and Archetypes of a health record, representing the global characteristics of the components, aggregations and context and ethico-legal information. It defines the set of classes that form
Page 17 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
the generic building blocks of the EHR. It fundamentally reflects the common, global characteristics of an electronic health record, which could then be shared, federated and distributed across multiple sites. The purpose of a Reference Informational Model is to act as a semantic basis for developing the next layer of models – the archetypes.
3.1.2 Archetype Model The Information Model is augmented by an organisational structure of defined classes of data items that may be organised into particular combinations. An Archetype is an explicitly formal definition of such pre-coordinated combinations of data items. It specifies (and effectively constrains) a particular combination of data items; their names, values, ranges, optionality and multiplicity.
Figure 5: Archetype Design Process and Repository [12]
Since archetypes are underpinned by and place constraints on the reference information model, they cannot invent structural semantics of their own, but they need structural semantics, as required by the numerous actual types of clinical content. For example, an Apgar result requires some notion of time (there are always at least 2 samples), and some notion of a list of ordinal values, with a sum. A glucose tolerance test result requires a notion of time, some idea of patient state (fasting, post glucose challenge), and a group of values. A few useful archetype design patterns are provided in Table 1.
Page 18 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Pattern Explanation In observation data, separate out data (actual Data / State / Protocol / Reasoning datum being recorded e.g. BP) from patient state (e.g. lying, standing) and protocol (cuff type, instrument type) Provide a structure containing 1..* Events, History of Events allowing data and patient state at each one, supporting intervals, point events, and math functions, e.g. average/delta/maximum/minimum Generalised free-form tree for containing Tree Structure clusters of data items, e.g. the 5+1 Apgar items, numerous microbiology result items, etc. A way of recording current state in Order / State Machine progression through a standard state machine applying to any ‘order’ An aggregation concept acting as a ‘bucket’ Composition / Document for information recorded by a professional at a given time for a given subject of care. A pattern defining the connection between Participation parties (people, organisations, devices) and other information. A pattern defining relationships between Party / Role / Accountability parties, including those that are roles played by some underlying actor. Table 1: Archetype Design Patterns
Archetypes usually follow a formal Archetype Model and are applied to specific professions, specialties and clinical settings, and as such may be updated without affecting other archetypes, whilst ensuring the update does not invalidate previous versions of the archetype by ensuring a provenance trail of archetype development, which in turn ensures a consistent mapping between EHR systems, see Figure 5. Each specialty may create their own specific archetype model for their own internal use, but certain common archetypes may be shared via Archetype Repositories. Shared archetype models via repositories allow multiple EHR systems to interoperate reliably with the transient patient EHR to extract the right data structures and values, see Figure 6. The number of archetypes required within a particular community will depend upon its range of clinical and scientific activities. Such archetype constructions require intimate knowledge of the data schema of the internal clinical systems, messaging systems, reporting systems, data vocabulary, etc.. A formal language for expressing archetypes has been introduced called Archetype Definition Language (ADL). Any healthcare institution that conforms to the Information Model and a subset of the Archetypes will be able to exchange information reliably. Such archetype repositories may be consolidated regionally or nationally to allow the relevant archetype models to be downloaded and freely used.
Page 19 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Figure 6: Archetype Dissemination [12]
3.1.3 Semantic Interoperability
Cuesters and Walker et al. [13, 14] defines semantic interoperability as “Two information systems are semantically interoperable if and only if each can carry out the tasks for which it was designed using data and information taken from the other as seamlessly as using its own data and information”. In practice, this means health care records collected within one electronic healthcare record system can be transmitted and viewed by clinical systems without the need for further interpretation or translation.
A potential electronic health care record must not only define methods by which unstructured content may be machine organised into structured messages, but also define interfaces by which such structured messages may be transmitted and interpreted base on the receiving systems vocabulary.
Implementations of such electronic healthcare record standards conform to various interoperable aspects of such a dual-model approach is summarised below, based on Kalra [6]. 3.2 Health Level Seven (HL7)
HL7 is a messaging standard that is widely used in messaging across health care applications. That is, it is used to send structured, encoded, data from one application (such as the laboratory system) to another (such as the EHR). There are two major versions of HL7 in use today. One is HL7 v.2x, which defines messages that have been developed and refined over several years to reflect standardised reporting data sets for several aspects of a patient’s care in hospital, and are the most widely used internationally within a hospital information system and the other is HL7 v.3x, the Reference Information Model (RIM) which provides a much more robust ability to represent complex relationships. The RIM is a formal information model representing the core classes and attributes that will be required (in various combinations) by the different HL7 version v.3x messages. The RIM defines four major classes of information:
Entities, for example persons, organisations, places and devices; Roles, for example that of patient or employee;
Page 20 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Participation relationships, for example that between a patient and a clinician; Acts, for example the recording of appointments, patient encounters, observations, procedures.
While the RIM is not yet implemented by many EHRs, it can potentially be used for representation of translational research data in a form that can be exchanged with EHRs in the future. The HL7 consortium is constantly working to improve EHR messaging [5].
The HL7 Clinical Document Architecture (CDA) is a generic message structure for the communication of a clinical document, derived as a message model from the HL7 RIM. CDA Release Two, which has recently been passed as a standard, specifies the structural organisation of fine-grained information inside a document. This is now close to the scope of the CEN 13606 EHR specification.
Many vendors claim HL7 adherence, but that does not necessarily mean that their applications are easy to interface with other vendors claiming that they too adhere to HL7 as well. To address this issue of interoperability, the vendor and user communities have formed the Certification Commission for Healthcare Information8, to certify that vendors have implemented HL7 and other standards in such a way that the resulting applications can exchange data with a minimum of customisation. 3.3 Integrating the Health Environment (IHE)
Integrating the Healthcare Environment (IHE) is a recently-formed industry sponsored consortium seeking to promote interoperability between systems within specialist departments, such as radiology, and the conventional hospital systems used to order such investigations and to receive imaging study reports. It is working closely with standards organisations such as CEN and HL7.
Its most recent specification, still in draft form, is for Cross-Document Sharing (XDS). It defines registry and repository services that can function as a centralised or distributed warehouse for clinical documents. Through specific collaborations between the parties involved, it will be capable of supporting HL7 CDA documents and EHRcom (13606) equivalent structures, but not a full EHR. It is a primarily a storage, indexing and distribution mechanism, and is a practical complement to these other standards. 3.4 OpenEHR
The openEHR Foundation is an independent, not-for-profit organisation and community, founded in 2000 by University College London and Ocean Informatics [12]. It aims to facilitate the creation and sharing of health records by consumers and clinicians via open- source, standards-based implementations. openEHR aims to:
8 http://www.cchit.org
Page 21 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
promote and publish the formal specification of requirements for representing and communicating electronic health record information, based on implementation experience, and evolving over time as health care and medical knowledge develop; promote and publish EHR information architectures, models and data dictionaries, tested in implementations, which meet these requirements; manage the sequential validation of the EHR architectures through comprehensive implementation and clinical evaluation; maintain open source “reference” implementations, available under license, to enhance the pool of available tools to support clinical systems; collaborate with other groups working towards high quality, requirements-based and interoperable health information systems, in related fields of health informatics.
openEHR proceeds with domain and problem analysis, formulates requirements and design principles, then develops architectural specifications, and then initiates implementation projects that, through iterative refinement and testing, are used to validate and improve the architecture and requirements.
The openEHR technical specifications define design principles, reference and models and will in future include other middleware service specifications. It is becoming regarded internationally as the most complete and best-validated EHR information architecture. openEHR works closely with the standards bodies to ensure that its own designs conform to current standards, and to contribute its experience and designs to future standards. The contribution of the archetype approach into CEN and HL7 is one example of this. 3.5 CEN13606 (ISO Draft Standard)
The CEN Reference Model for EHR Communication is a generic model capable of representing the structure and context of part or all of the electronic health record of one subject of care, to support interoperable communications between systems and services that might request or provide EHR data. It is not intended to specify the internal architecture or database design of such systems [6]. In some respects it is a meta-EHR, where the implementation may be specified in any EHR specification, including the ones listed above.
CEN 13606 is a five-part standard:
Part 1: Reference Model is a comprehensive, generic EHR model and is mapped to the HL7 RIM and Clinical Document Architecture; Part 2: Archetype Interchange Specification is an information model and exchange syntax for communicating archetypes; this specification is an adoption of the openEHR archetype approach, and will also be compatible with the emerging HL7 Template specification; Part 3: Reference Archetypes and Term Lists will contain a set of vocabularies and term lists to support the Reference Model, guidance on how to use the Reference Model classes and attributes, and how to design archetypes; Part 4: Security defines measures to support access control, consent and auditability of EHR communications;
Page 22 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Part 5: Exchange Models defines messages and service interfaces to enable EHR and archetype communication.
There is wide international interest in this CEN work, and Part 1 has also been adopted by the International Organisation for Standardisation (ISO) as a draft standard for consultation and subsequent voting. ISO is presently reviewing the other draft parts of 13606 as they become available, to consider if these are also candidates for international standardisation. CEN 13606 standard is also known as the ISO13606 standard due to the ISO certification and approval process. Henceforth, this will be designated CEN13606 throughout this document.
The standard considers the EHR to be the persistent longitudinal and potentially multi- enterprise or multi-national record of health and care provision relating to a single subject of care (the patient), created and stored in one or more physical systems in order to inform the subject’s future health care and to provide a medico-legal record of care that has been provided. Whilst an EHR service or system will need to interact with many other services or systems providing terminology, medical knowledge, guidelines, workflow, security, personal registries, billing, etc. This standard has only touched on those areas if some persistent trace of such interactions is required in the EHR itself. The standard may offer a useful contribution to the design of future EHR systems but will primarily be realised as a common set of external interfaces or messages built on otherwise heterogeneous clinical systems. It seems reasonable to assume that a multi-vendor “mixed economy” of specialist and general clinical systems will continue to evolve internationally in the coming years. The 13606 Reference Model defines a core hierarchy of building blocks to which any EHR can be mapped.
It is important to note that CEN 13606 is a specification for exchange of EHR Extracts (portions of EHR documents that allow interoperability), not for a full EHR system. There are many more requirements for an EHR system, including version management, workflow management, interfaces to other systems, etc.. Some of these requirements impact upon the Extract. The specification is somewhat of a “lowest common denominator”, which in a sense all standards are. CEN 13606 is not the place to expect to see all the requirements one has for EHR systems, only those relating to moving pieces of the EHR from one system to another. openEHR only provides a full specification for the creation, storage, maintenance, and querying of EHRs, but does not include a specification for the communication between multiple EHR systems. Neither CEN 13606 nor the HL7 RIM defines a reference model for an EHR, but rather depend on other EHR implementations to define the key aspects of an EHR.
The CEN 13606 standard via the openEHR implementation standard has been used to develop the national EHR specification for Sweden (Swedish National Patient Summary) and is currently being evaluated for Denmark, Slovakia, Chile and Brazil. It is beginning to be utilised in commercial systems throughout the world.
Page 23 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
4 PATIENT AVATARS
As discussed earlier the concept of a Patient Avatar is like a large catalogue of every item of data, information and knowledge on a patient or a collection of patients that can be shared securely, to allow it to be searched, browsed, interactively explored, for a broad range of reasons, including leisure, education, healthcare, etc.. In particular, with respect to scientific workflows, the possibility to find, retrieve, and reuse all of the data, information and knowledge that is available on patient and their physiological attributes could truly revolutionise the field, increasing exponentially the potential users for VPH technology. The Patient Avatar requires a holistic and consistent view of the patient and therefore has a close relationship with and exploits the technologies discussed in Section 3.
The Patient Avatar could truly transform the way science and medicine is performed by:
integrating fragmented data and knowledge into a single cohesive unit of data; creating a centralised repository with reliable population and patient data around which VPH tools and applications could be built; providing diagnostic or prognostic decision and treatment planning support using predictive models built around a patient-specific avatar; providing a comprehensive yet averaged overview of a patient based on generic population phenotype to explore and test ideas virtually.
Creating a Patient Avatar from biomedical data poses a huge challenge due to the degree of heterogeneity in type, uncertainty, resolution, etc.. Most of data these days are machine generated, which in the absence of semantic definition further compound the problems of scale and comprehension.
Avatar, literally means embodiment or manifestation, and a Patient Avatar within the VPH project embodies a strategy to not only catalogue every data item relevant for each of the VPH-Share flagship workflows, but also to use the Patient Avatar to help deduce relevant missing data items from all available VPH data sources and population data and provide appropriate average values and related variability and uncertainty inferred for a specific patient. It is a key strategy to help integrate available, but sometimes sparse, scattered and inconsistent clinical information within a personalised Patient Avatar representation.
It is also important to note that the proposition of integrating such disperse clinical data for application to clinical application focussed research is not the only goal of this document. A Patient Avatar used within the scope of the VPH-Share project, aims to be a dynamic document that not only holds personal information, clinical evidence, physical assessments, treatment plans and a sequence of temporal entries, which could prove to be overwhelming when gathered over a lifetime, but is also able to add value to both clinicians and patients alike. The project envisions the Patient Avatar to be ultimately controlled by the patients themselves in the guise of a Personally Controlled Patient Avatar (PCPA) to create a hub of personal, relevant and contextual health information in one place. Such movements have
Page 24 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
already begun with initiatives like Google Health9, Dossia10 and Microsoft Health Vault11. However as the failure Google Health pointed out “…knowledge may be power, but not will power…”, patients require more than static silos of aggregated information, they want added value. Projects like PatientsLikeMe12 aims to add value by adding a social layer that allows patients engage with other patients with similar issues and concerns through Personally Controlled Electronic Health Records (PCEHR). Such transitions require both technological and sociological change that can be driven by focussed outreach, education and delivering trust and value to both clinicians and patients. 4.1 Patient Avatar & Workflows
VPH-Share has chosen to exemplify the patient avatar concept by using four flagship workflows. Each of the four ‘flagship’ workflows simplifies the complex chain of events associated with normal and abnormal functioning of a physiological process within a human being or a population. This functional simplification is embodied as a mathematical or computational model that describes the sequence of events with certain assumptions. A modeller uses these assumptions and parameterises the model, ultimately creating a generic description (model) that can help answer the research question of interest.
Generic models may be transformed to represent a specific subject (patient) using parameters derived from clinical or statistical measurements. Such introductions of computational modelling techniques may not only provide us insights into the progression of a disease, but also help predict the response to altered physiological conditions, supporting diagnostic and prognostic therapy planning.
The potential integration of clinical, genetic, epidemiological, demographic and biological information with support from advanced computational and image processing techniques is of particular interest to all four workflows. In fact, all four workflows have already attempted to integrate the clinical and workflow relevant information into their own respective pipeline internally. The Patient Avatar is an attempt to expose commonalities and specificities into a global representation of a patient to help integrate and augment the data items with scattered external data, and allow workflows and other VPH projects interoperate with each other.
Deep integration of mathematical and computational models into clinical practice for therapy planning can create new opportunities to gather workflow relevant clinical parameters from improved standard data acquisition protocol. A typical workflow, from the @neurIST project, which moves from the patient to disease event risk assessment via a disease simulation model, is shown in Figure 7. The disease simulation model is composed of multiple computational and/or mathematical models that represent the various aspects of the physiological process in general. The model is tuned using parameters derived from patient- specific data.
9 http://www.google.com/health/ 10 http://www.dossia.org/ 11 http://www.microsoft.com/en-us/healthvault/ 12 http://www.patientslikeme.com/
Page 25 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Figure 7: Computational Biomechanics Workflow: Patient to Risk Assessment [15]
However, many of the parameters required for the simulation may not be part of standard data acquisition protocol and hence may need to be derived from literature and statistical models. Patient data are also not usually single scalar quantities, but are often represented as a range of values measured at different times and states of the patient. The disease simulation model almost always represents an ideal generic case, where the variability and uncertainty of the patient data is not taken into account. Tasks 5.1 Parameter Estimation and 5.2 Physiological Envelop for Simulation and Model Interpretation with the VPH-Share attempts to bridge the gap by introducing parameter estimation and uncertainty envelope libraries for simulation models.
The parameter estimation process requires access to a large amount of literature, population data and a large number of statistical models. An effective “average” patient avatar could be used to cluster the individual patient avatar population based on the specific phenotypes and extract that distribution (average and deviations) for use instead of the missing parameters. This can only be possible with deep integration of multiple sources of patient data within a single format.
As mentioned earlier, one of the important goals of the VPH-Share project is the immense, disperse and heterogeneous data resources that will be made accessible though the VPH- Share infostructure. The VPH community, as a whole, is data hungry and the project aims to expose a wide range of data from aggregated clinical record data for millions of patients to very deep and heavily populated (anonymised) data for specific patient cohorts from local, regional and national institutions. Such breadth of data exposure will further amplify the need
Page 26 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
for a patient avatar to help organise all clinical data required as the basis for the construction of the VPH-Share flagship workflows. According to the VPH-Share DoW, the consortium partners have identified and agreed to potentially release a number of tools, models and importantly with respect to this document clinically relevant data (anonymised and subject to data governance). The members of the VPH-Share consortium have identified potential data resources summarised in Table 2, but further potential data resources can be made available through the outreach partners.
Domain Description No: of records Partner
Cardiac euHeartDB, images and EHR ≈ 50 KCL
EHR, Labs, ECG, Images ≈ 200 Cardiology STH (heart failure, PHS) ≈ 15
Heart Disease Clinical Audit (10 year period) ≈ 1.4 million NHSIC
EHR, Lifestyle demographics, Images, Neurovascular ≈ 300 UPF Derived data
Cerebral Several data sets containing clinical TBD NHSIC Aneurysms episode information and outcomes
Orthopaedic EHR, Images, OpenClinica Data ≈ 240 IOR
Several datasets containing clinical Osteoporosis episodes and hip fracture audits and TBD NHSIC outcomes
HIV Anonymised Patient Data ≈ 300 UvA
Multi-Domain Admitted patient care data ≈ 300 million NHSIC
Health outcome measures from over Multi-Domain TBD NHSIC 300 clinical specialities
Diabetes National Clinical Audit ≈ 1.7 million NHSIC
Bowel Cancer Clinical Audit (8 year period) ≈ 100,000 NHSIC
Lung Cancer Clinical Audit (3 year period) ≈ 84,000 NHSIC
EHR, vital signs, previous personal and Subset of ≈ 2 Multi-Domain family history, risk factors, physical FRCB million examination, labs, images… since 2008
Page 27 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Catalan Region Image data from currently 8 large public and 3 private ≈ 150 Tb pa of Multi-Domain hospitals. Potential is for 40,000 medical AATRM clinicians, 7.5 million patients, 7.5 images patient-studies per annum.
Table 2: Data resources available to VPH-Share (subject to licence and governance) 4.2 Patient Avatars & EHR Standards
The review of Electronic Health Records in the previous section drew upon the parallels between a challenge to define a cohesive Patient Avatar and the challenge of creating a universal Electronic Health Record standard. Much of what is contained within a Patient Avatar will already exist in the form of an EHR or something similar within a healthcare organisation. Within VPH-Share, the aim is not to create yet another new standard for scientific research, see Figure 8, but rather to reuse an existing standard and help integrate with existing clinical systems.
Figure 8: The Problem of Standard Proliferation [16]
An ideal EHR standard would be one that is already used extensively throughout the VPH community and complements each of the workflows with predefined archetypes, see Figure 9. However such an EHR standard does not exist, but as described in the previous sections, there are quite a number of standards available, in fact a proliferation of them, and still more respective archetype models. As described in previous sections, a small selection of some of the most widely used are: HL7 CDA, CEN 13606, openEHR and IHE [5, 6, 10], but as part of this deliverable, we do not aim to commit to one standard for our project, but rather choose a standard as a prototype for describing our concept of a Patient Avatar.
Page 28 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Figure 9: Patient Avatar Interoperability
Given our challenges in achieving interoperability between the domains and the given the proliferation of standards and industry initiatives keen to address the problem; the key questions we aim to ask of each standard are:
Functionality: Does the standard support different methods of information retrieval? Complementarity: Since different standards have different features. Can the standard be combined with other standards in a complementary way? Market Relevance: What is the level of uptake by the industry and healthcare domains?
Based on our own literature survey and that of Eichelberg et al. [5], the two standards that show promise are openEHR and CEN 13606. On looking closer at the standards from previous sections, we see that the CEN 13606 standard is not really a fully-fledged EHR solution, but rather a standard that allows EHRs to interoperate with each other via EHR extracts. openEHR on the other hand claims to be a future proof EHR solution that has slightly more features than CEN 13606, but follows the same concept of Archetype Models, see Figure 10.
Figure 10: Schematic Relationship Between HER Standards [17]
Page 29 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Based on our evaluation we have chosen to represent the Patient Avatar using the CEN 13606 standard due to the interoperability features of the standard, but with core implementation aspects covered by openEHR.
4.2.1 Why openEHR + CEN 13606?
The reasons for our choice of openEHR combined with the CEN 13606 standard to represent the Patient Avatar are summarised from [18]:
openEHR is open source. It breaks down the proprietary silos of data created by application vendors. openEHR is the basis for the CEN 13606 standard for EHR extract. At present openEHR is the commonest implementation pathway for nations mandated to adopt the CEN 13606 standard. openEHR is driven by an international open source community. openEHR has been developed using a robust engineering process. Both standards use a small information model and rely on the use of large archetype model, which suits most applications within the VPH. The clinical content is driven by the domain experts – usually, but not limited to the clinicians themselves – through the Clinical Knowledge Manager13. Archetypes are designed as maximal data sets for the universal use-case so the same data definitions can be used in any software application – whether a PHR (Personal Health Record), EHR, research project, clinical decision support system or running population queries. They are purpose-designed as a shared health record. Even though openEHR does not interoperate between EHR systems CEN 13606 helps achieve interoperability through EHR extracts. CEN 13606 is already being used as the basis for the Swedish National Patient Summary and being considered in Denmark, Slovakia, Chile and Brazil.
4.2.2 Patient Avatar (CEN 13606 + OpenEHR)
A key strategy to the successful creation of a useful Patient Avatar is to employ an Avatar Design Methodology. The design methodology details the essential steps to be performed by each healthcare organisation and/or research unit to identify the key information process flows and relevant data items. It is essentially a protocol that permits patient avatar compliance across multiple organisations and institutions. The design methodology is detailed below:
1. Document the information process flows for the domain to be modelled identifying the key information sources such as data formats, paper documents, electronic documents and medical devices. 2. Determine all clinical items in the domain to be modelled based on the key information sources identified in the process flow analysis.
13 http://www.openehr.org/knowledge/
Page 30 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
3. Merge related individual clinical items to single archetype clinical concepts. 4. Where possible, map the derived clinical concepts to existing archetypes. 5. Data model the clinical concepts identified and re-model them to eliminate duplication of items. 6. Model new archetypes for clinical concepts that cannot be mapped to existing archetypes. 7. Create templates to group and constrain related archetypes that represent the contents of locally used forms or data documents. 8. Document archetype design patterns for reoccurring scenarios or design issues that have arisen during archetype design. 9. Publish newly created archetypes to the VPH and openEHR archetype knowledgebase for validation and feedback from archetype design experts. Allow others to share the knowledge that you have created. Incorporate this design feedback into archetype design patterns and document where appropriate.
These steps entail a detailed and intimate look at the information process flows within a domain. The four ‘flagship’ workflows serve as the key domains providing a practical framework with which to create a Patient Avatar. This document serves as a detailed initial attempt at describing the first eight steps in the creation of a Patient Avatar see Section 4.2.1. The next few sections clarify the processes of detailing the information flow and identification of relevant data items for each ‘flagship’ workflow. Subsequent revisions of this document will consider the creation of an archetype and information model based on this information.
4.2.3 Ethical, Legal and Security Constraints
In the context of transfer of data and data sharing, the role of VPH-Share is to provide the organisational fabric (the infostructure), to expose and to manage data and to facilitate collaborations between the members of the VPH community. The Clinical and Ethics Board (CEB) within VPH-Share will address the ethical and legal requirements of data sharing and will seek to identify challenges and risks associated.
VPH-Share will confine its role to that of a ‘data processor’. The role of the ‘data controller’ (holding and providing data) will remain solely with the home institution associated with the data source (i.e. the institution responsible for ethical permissions and governance issues relating to the holding and sharing of a specific dataset). VPH-Share will not be collecting any new data. All data to be shared will be provided by the data controller and rendered anonymous prior to data release to the VPH-Share community and beyond.
Within VPH-Share draft ‘data transfer agreements’ and agreed protocols for the transfer and sharing of data will also be developed.
Page 31 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
5 WORKFLOW INFORMATION MODELS
The primary purpose of this section is to characterise the two primary aspects of the complex information processing chain within the four flagship workflows, namely (a) steps that describe the flow of information, and (b) the data transferred between the various implicit and explicit steps involved in each of the analyses.
Each workflow will provide a brief overview of the key information processing steps and the explicitly describe the transformations undertaken within each step and the data conversions that occur. An architectural context will also be provided to further strengthen the relationship between the workflows and the data-sharing environment they reside. The key workflow elements will then be further described in increasing granularity to clarify the implicit and explicit step undertaken in minute detail. Such descriptions will amplify the implicit clinical data requirements that are required to execute any or all parts of the workflow. Legal, ethical and security constraints regarding such patient specific data will also be covered. 5.1 @neurIST Workflow Information Model
This section primarily describes the Workflow Information Model adopted by the @neurIST flagship workflow as part of the VPH-Share project. The selected @neurIST workflow classifies a complex information processing chain, which originally comprised morphological, haemodynamic and structural characterisations of intracranial aneurysms appearing in a medical image. The VPH-Share @neurIST workflow concentrates on the morphological and haemodynamic characterisations, and will exclude the structural measures.
Figure 11: Complex information processing workflow (@neurIST example)
The VPH-Share @neurIST workflow is summarised in Figure 11. The complex information tool chain starts from a medical image and obtains a 3D mesh representing the vascular
Page 32 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
geometry to be analysed. Once the segmented surface mesh is available, it is manually manipulated to remove some of the artefacts not belonging to the cerebral vasculature or not relevant for the subsequent analyses. As a result of the morphological characterisation, a collection of morphological descriptors of various complexities is computed. These include basic size indices (aspect ratio, non-sphericity index, aneurysm volume and surface area) and three-dimensional Zernike moment invariants. For the haemodynamic characterisation, two complementary haemodynamic analyses are carried out as part of this chain. The global one is based on a one-dimensional model of the human systemic circulation, and predicts flow rate and pressure waveforms at predefined points (selection of boundary conditions). As a result of this characterisation, a set of qualitative and quantitative descriptors (candidate risk factors) are extracted from the flow solution automatically, except for a few qualitative ones such as flow stability and intra-aneurysmal flow type requiring expert judgement.
Four primary challenges can be associated with the @neurIST complex information processing (morphological, structural and haemodynamic characterisation) workflows, namely:
1. To define a sequence of operations that produces the most appropriate representation of the individual as the basis for computation of the characteristics (the pre-processing or model-building step). 2. To solve the numerical model to return the ‘raw’ results (the solution step): for the structural and haemodynamic analyses this produces very large data files. For the haemodynamic analyses they contain (at least) numerical values for pressure and for the three components of velocity computed at something of the order of a million points, potentially at a hundred or more time steps. Thus the raw solution files contain of the order of 109 entries for each transient analysis. 3. To perform data reduction operations to reduce the raw data to a few characteristic measures that are tractable as the basis for statistical association studies (the post- processing step). 4. To construct the IT environment able to support all of the above operations, accessing data or models as required and writing the output to the appropriate locations.
The formulation and definition of the complex information processing chain operating on the clinical datasets to return morphological, structural and haemodynamic characterisations to the @neurIST databases has been the subject of a number of publications as part of the @neurIST project [3, 19-35].
The two fundamental use cases for the complex information processing analysis chain in @neurIST and classified as being part of VPH-Share are:
The population of the databases with morphological, structural and haemodynamic characterisations of the aneurysms to support subsequent statistical association studies. The ‘clinical use case’, or use by clinicians to characterise an individual’s aneurysm. This will potentially be further extended in future projects to ask ‘what if’ questions with respect to the envelope of likely physiological exposure and with respect to potential interventions.
Page 33 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
The following two use cases will not be part of VPH-Share:
The ‘research use case’, or use by researchers to explore the association between input parameters and characteristic measures. The ‘industrial use case’, or use in the context of design of interventions, in the context of @neurIST particularly with respect to stent design.
In VPH-Share, the individual components of the complex information processing tool chain will be available to the users. This will enable either be the reproduction of @neurIST use cases or the creation of new ones.
The @neurIST databases were populated with parameters that describe the morphological, structural and haemodynamic characteristics of the aneurysm. These new characterisations are thought to represent better diagnostic or prognostic indicators than those previously available.
Such characterisations are inextricably linked to the @neurIST ‘virtual patient metaphor’ (VPM) [15] but has implications beyond @neurIST as part of the ‘Patient Avatar’ under development in this deliverable within VPH-Share. The ‘Patient Avatar’ as part of this deliverable is envisaged as an abstract clinical patient information document that can be queried for any and all relevant information about a patient. It is conceptually almost infinite in extent, containing all of the prescribed clinical information that describes a patient. In the context of the @neurIST workflows, the ‘Patient Avatar’ represents all of the primary measured data (including medical images) that might be required as input to any particular analysis process, but also extends to references to secondary and tertiary data that may be used to derive primary data if it is unavailable. In principle, in VPH-Share there will be a ‘Patient Avatar’ for every individual, but there may also be a collection of ‘Patient Avatars’ for certain relevant phenotypes and even a generic ‘Patient Avatar’ averaged from a whole population. In principle each VPH-Share-@neurIST clinical case will be associated with a ‘Patient Avatar’.
The ultimate goal of the @neurIST flagship workflow is to identify those aneurysms that are likely to rupture, or progress to rupture within a particular period of time. It is likely that the event of rupture itself occurs when the stress or strain in the aneurysm exceeds the strength of the tissue in the individual, and it is reasonable to assume that this is most likely to occur when the pressure is highest. A ‘Patient Avatar’ will be used to describe the individual with suitable patient-specific data for analysis. However, not all of the patient-specific characteristics may be routinely measured, and hence the ‘Patient Avatar’ may need to be augmented with reasonable estimates from average phenotypes. As such a combination of measured and inferred patient parameters will be used to describe a ‘Patient Avatar’ that will be used for processing. Such inferred measurements will be acknowledged to the user and will use the tools and libraries created in Task 5.1 (Parameter Estimation) and Task 5.2 (Physiological Envelope for Simulation and Model Interpretation) to ensure that the physiological variability and uncertainty estimates are propagated through into the modelling and simulation phase.
Page 34 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
5.1.1 Overview of Key Workflow Elements
To define the VPH-Share ‘Patient Avatar’ within the context of the @neurIST project, we will attempt to identify:
every single operation in the information processing chains; every single source and sink for each data item and recommendations for alternate secondary and tertiary derived data item; every single explicit recommendation on each strategic decision, including legal and ethical issues associated with each data item.
A brief overview of each processing step is presented below and in turn each step is presented with increasing granularity. Each of the information processing chains, namely morphological and haemodynamic, are organised as three-step chains and share the following considerations when translated to VPH-Share (see Figure 11):
Pre-processing – Building the Model: The specification of the analysis protocols is theoretically a straightforward task in a mechanical sense, but there are many deep philosophical issues associated with the question of what is the ‘right’ analysis to do for a patient, and whether this is different from the analysis that should be done for the purposes of building databases from which to extract statistical association. In terms of the challenges listed above, @neurIST’s greatest difficulty arose with respect to the pre- processing chain. What were the right analyses to perform? There were tens of input parameters, and many were continuous variables that could take any value over normal and pathological ranges: for example if diastolic blood pressure was an input then it could range from perhaps 50 mmHg as a resting, overnight figure to perhaps 110 mmHg or more under a stress condition. Each dataset could therefore give rise to an infinite number of variations: even choosing just three representative values, perhaps low, medium and high (even this begged the question as to whether these values should be based on normal diurnal variations or on unusual or pathological events) for each parameter could lead to hundreds of analyses for each individual. Clearly this was not reasonable, not least because it was not clear what would be done with the information generated.
The Solution Step: The solution step is straightforward: once the model has been built, it is necessary to generate a solution that describes the distribution of the fundamental variables at all points in the domain (or for a morphological analysis to produce appropriate, perhaps global, descriptors of the geometry). There is a professional responsibility to ensure that the solution generated is an accurate one forin respect of the problems posed (for example by performing mesh sensitivity studies), but there are no significant philosophical issues. As stated above, in @neurIST the solution step typically produced very large results files, potentially of the order of tens of Gigabytes if results were stored at every time step. The computational resources used to create the solutions are not trivial. A transient haemodynamics analysis of a typical aneurysm in CFX (a commercial computational fluid dynamics program from ANSYS) took of the order of a day on a single processor of a modern PC-cluster. Clearly it was neither possible to store
Page 35 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
the solution results in @neurIST, nor will be in VPH-Share. In VPH-Share, only the result summary of the solution will be linked to the original ‘Patient Avatar’ along with a link to computational model source file used to perform the simulation.
Post-processing – Storage and Data Reduction: @neurIST needed to establish a strategy for storage and analysis of the data produced. As discussed in the solution step, the computational resource consumed in the analysis is significant. Each analysis might take one CPU day. This document will explore the issue of how many analyses will be conducted for each patient. For example, in case of carrying out only a single analysis for four hundred aneurysms (the @neurIST project case), four hundred CPU days would have been required. In addition, we would have still missed accounting the human resource involved in managing these analyses. Therefore, data reduction operations had to be defined to reduce the vast quantity of data to a manageable volume that might feasibly be used to seek statistical association between the physical characterisations and the event of rupture. However, although best efforts were made to choose the most appropriate characteristic parameters, it was arguably best to save all raw output data so that new characterisations, suggested by new knowledge, might be computed in the future without re-running all of the analyses. To give a rough order of magnitude, if two analyses had been stored for each of the four hundred aneurysms analysed during the duration of @neurIST, the project would have generated something of the order of 5 Tb of raw haemodynamic data. As done in @neurIST, VPH-Share has chosen to post-process the raw solution results so that clinically relevant results such as ‘probability of rupture’, etc. are placed directly into the ‘Patient Avatar’ document along with a link to the simulation model used and a link to the raw results data, if archived on the storage infrastructure.
5.1.2 VPH‐Share Architectural Context
VPH-Share is primarily an infrastructure project that aims to serve the four flagship workflows in the first instance. WP2, WP3, WP4 and WP6 aims to develop tools and technologies that will enable the flagship workflow refactor tools and services into the tool and data-sharing environment created. The @neurIST workflow aims to repackage and deliver a few key applications as web services for consumption by the VPH community. It will also deliver key clinical anonymised datasets collected as part of the @neurIST project. Each key workflow element described below will form part or full ‘atomic’ web services that will be delivered as deliverables to the VPH-Share infrastructure.
5.1.3 Key Workflow Elements
Step 1: Creation of a ‘complete’ Geometry Representation
The creation of a surface representation of the region of the aneurysm is required for all components of the complex information processing chain, which includes the morphological and haemodynamic components of the workflow. The creation and augmentation of a surface representation involves image segmentation and the generation of a surface mesh from the segmentation result, using a software tool such as @neuFuse or GIMIAS. In addition to topology corrections, the tool also needs to allow the operator to add a skeleton to increase the reproducibility of defining cutting planes.
Page 36 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
The appropriate surface meshes to support each of the characterisation operations are unlikely to be the same, particularly with respect to the extent of the domain. For the morphological characterisation the cutting planes that will close the domain are near to the neck of the aneurysm. For the haemodynamics tool chain, they will be more distant and will be associated with the inlets and outlets for the fluid domain, as well as providing the interfaces to a one-dimensional systemic circulation model. In general, the 3D haemodynamic analysis is likely to require a larger portion of the domain than any of the others, but it might also require operations such as vessel removal and/or inlet/outlet extensions that might not be appropriate for morphological and structural characterisations. For the purposes of the @neurIST workflow it is assumed that all operators will be trained to produce a representation of adequate quality for a haemodynamics analysis, and that the stored surface representation is the best that can be achieved. There will be situations in which the raw image is not of adequate quality to support haemodynamic analysis, and the responsibility for identification of these situations will lie with the operator performing the haemodynamic analysis. Step 1.1: Reading and Visualising the Image
The analyst is able to select and retrieve a medical image from an image repository (local or remote); visualise it together with image modality, size and resolution; and manipulate it. Step 1.1.1: Reading the Medical image Input Data Processing Step Output Data
1. Case Number Analyst enters case number 1. DICOM Image Source: Local or remote and accesses screen displaying Format: DICOM image repository available medical images for Attributes: image modality, Format: Alpha-Numeric this case. size, resolution
Analyst selects one and the image is loaded.
Step 1.1.2: Visualising the Medical image Input Data Processing Step Output Data
1. DICOM image Analyst is able to visualise the 1. DICOM Image Source: Local or remote medical image and manipulate Source: VPH-Share medical image repository it (zoom in/out, pan, rotate). image viewer Format: DICOM Format: DICOM Units: meters Attributes: image modality, size, resolution
Step 1.2: Region of Interest Selection and Image Segmentation
To obtain a tractable surface mesh suitable for the subsequent analyses (morphological and haemodynamic), the vessels contained in the original image need to be segmented.
Page 37 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Step 1.2.1: Image Region of Interest Selection
A basic pre-processing step is performed before segmentation: selection of the region of interest in the original image, to restrain to the part of the vasculature that will be considered in the haemodynamics toolchain (the morphological characterisation requires a subset of this domain). Input Data Processing Step Output Data
1. DICOM Image The analyst selects the image 1. Region of interest Source: VPH-Share medical and specifies interactively the parameters image viewer region of interest parameters. Source: VPH-Share ROI Attributes: image modality, selection atomic service size, resolution These are passed to the Format: key:value Units: meters segmentation algorithm and are written in the segmentation 2. Audit Trail audit trail. Source: VPH-Share ROI selection atomic service Format: Text
Step 1.2.2: Image Segmentation
The vasculature present in the selected region of interest is segmented using the default segmentation settings. The image segmentation algorithms uses internally a triangle marching cubes algorithm to obtain the surface mesh needed for the subsequent analyses (morphological and haemodynamic). Input Data Processing Step Output Data
1. DICOM image The analyst selects the image 1. SG (segmented Source: VPH-Share medical region of interest. The image geometry) image viewer is retrieved. Source: VPH-Share image Attributes: image modality, The analyst starts the segmentation atomic service size, resolution segmentation algorithm, Format: Surface mesh Units: meters leaving the default Attributes: Audit trail: segmentation settings. Name; Date; Format; 2. Region of interest A triangle marching cubes software module version; parameters algorithm is run to obtain a software module operator; Source: VPH-Share ROI surface mesh of the region of interest selection atomic service vasculature. parameters; Segmentation Format: key:value method and settings (if appropriate); Source image name, modality, resolution Units: meters
Step 1.3: Mesh Editing and Skeletonisation
The surface mesh resulting from the segmentation atomic service needs to be further repaired and several editing operations are necessary. Skeletonisation operations further augment the aneurysm-processing pipeline.
Page 38 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Step 1.3.1: Mesh Editing
Mesh editing operations include a smoothing operation (chosen to minimise shrinking and other errors) and safeguards will be in place to monitor and record measures of the difference between the originally segmented surface and the smoothed ones. The surface mesh elements need to be labelled to indicate whether they lay on the wall or on a numbered opening (inlet or outlet). These labels might subsequently be used to associate pressure or flow boundary conditions for the haemodynamic analysis. Input Data Processing Step Output Data
1. SG Analyst selects the surface 1. G (corrected geometry, Source: VPH-Share image mesh resulting from the surface mesh) segmentation atomic service segmentation and repairs it Source: VPH-Share mesh Format: VTK using tools available in the editing atomic service Attributes: SG audit trail mesh-editing atomic service. Format: Surface mesh Units: meters Analyst also performs the (VTK) appropriate cuts on the surface Attributes: Audit trail: mesh so that it is suitable for (append to the input Audit the future haemodynamic trail of SG) Name; Date; analysis. Format; software module The surface mesh of the version; software module vasculature is saved to a operator; list of operations named storage location and and settings the Patient Avatar is updated Units: meters to indicate that the corrected patient vasculature is available.
Step 1.3.2: Skeletonisation
Skeletonisation (a line representation) of the 3D domain of the aneurysm can be useful in the development of a pipeline for reproducible and consistent closing of the domain. The skeletonisation process starts from the repaired, cleaned and smoothed surface mesh. Input Data Processing Step Output Data
1. G Analyst performs 1. SKEL (Skeleton, vessel Source: VPH-Share mesh skeletonisation of the centreline parameterisation) editing atomic service corrected surface mesh using Source: VPH-Share Format: VTK the skeletonisation atomic skeletonisation atomic Attributes: G audit trail service. service Units: meters Format: VTK (node The skeleton of the locations, element vasculature is saved to a connectivity, elements named storage location and labelled to describe the Patient Avatar is updated boundary component to indicate that it is available. membership) Attributes: Audit trail: (append to input audit trail
Page 39 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
of G) Name; Date; Format; software module version; software module operator; skeletonisation algorithm settings Units: meters
Step 2: Morphological Characterisation Chain
The purpose of the morphological characterisation is to reduce the geometry of the aneurysm to a limited set of descriptors that represent shape in a condensed way. The morphological descriptors will be returned as part of the processing results. The morphological characterisation tool chain shares all pre-processing steps (segmentation, mesh editing and skeletonisation) in common with the haemodynamics tool chain, but uses a different set of cut planes for extracting the shape on which shape indexes are computed.
Step 2.1: Neck Selection
Morphological and haemodynamic analyses need to separate the aneurysm/aneurysms from the rest of the vasculature as part of the processing protocol. VPH-Share will provide support for interactive definition of so-called neck surfaces separating saccular aneurysms from the rest of the vasculature. This neck definition will be used for the morphological characterisation. In the case of the haemodynamic analyses, initially VPH-Share will use the neck definition provided in ANSYS ICEM and in a second stage will try to reuse the VPH- Share neck definition used in the morphological analysis. Input Data Processing Step Output Data
1. G Analyst performs neck 1. NECK (Skeleton, vessel selection for an aneurysm in centreline parameterisation) Source: VPH-Share mesh the corrected surface mesh editing atomic service using the VPH-Share neck Source: VPH-Share neck selection atomic service. selection atomic service Format: VTK The aneurysm neck/necks of Format: VTK (node Attributes: G audit trail the vasculature is/are saved to locations, element a named storage location and connectivity) Units: meters the Patient Avatar is updated to indicate that it is/they are Attributes: Audit trail: available. (append to input audit trail of G) Name; Date; Format; software module version; software module operator; aneurysm ID
Units: meters
Page 40 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Step 2.2: Aneurysm Isolation
The morphological analysis is performed on the aneurysm shape and a portion of the surrounding feeding vessels. A cutting protocol is specified [36] to perform the cuts at every inlet and outlet. Input Data Processing Step Output Data
1. G Analyst performs the cuts on 1. M_MA (2D surface mesh Source: VPH-Share mesh the corrected surface mesh for morphological analysis) editing atomic service using as a reference the Format: VTK skeleton, using the aneurysm 2. C_MA (cuts parameters) Attributes: G audit trail isolation atomic service. skeletonisation atomic Units: meters service The isolated mesh/meshes of Format: VTK (node 2. SKEL the aneurysm/aneurysms is/are locations, element Source: VPH-Share saved to a named storage connectivity, elements skeletonisation atomic location and the Patient Avatar labelled to describe service is updated to indicate that it boundary component Format: VTK is/they are available (together membership) Attributes: SKEL audit trail with the cut locations). Attributes: Audit trail: Units: meters (append to input trail of SKEL) Name; Date; Format; software module version; software module operator; cut planes Units: meters
Step 2.3: Computation of Morphological Descriptors
A collection of morphological descriptors of various complexities is computed among the wide variety available in the literature. Basic size indices such as aspect ratio, non-sphericity index, aneurysm volume and surface area are calculated for the aneurysm sac. Aspect ratio relates the aneurysm depth and neck width, while non-sphericity index relates the aneurysm volume and surface area. A set of more sophisticated descriptors called three-dimensional Zernike moment invariants are also used to characterise the aneurysm shape and a portion of the surrounding feeding vessels using a fixed cutting protocol at every inlet and outlet. Three- dimensional Zernike moments provide a complete three-dimensional morphological characterisation of objects, and their invariants remove scale and orientation dependency. These have shown for a small heterogeneous population promising rupture prediction rates. Finally, inlet and outlet vessel diameters are also calculated at the cut planes used to isolate the geometry for which the Zernike moment invariants are computed. All of these descriptors are automatically computed in real time from the isolated geometries of the sac and aneurysm plus a portion of the surrounding feeding vessels.
Page 41 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Input Data Processing Step Output Data
1. M_MA Analyst triggers the automatic 1. RES_MA (results of Source: VPH-Share analysis in the VPH-Share morphological analysis) aneurysm isolation atomic morphological analysis atomic Source: VPH-Share service service. morphological analysis Format: Surface mesh (VTK) atomic service Attributes: M_MA audit trail The computed morphological Format: DB entries, XML Units: meters descriptors are saved to a Scale factor, maximal order named storage location and considered, origin taken for the Patient Avatar is updated centring the aneurysm, accordingly. morphological characteristic measures (width of the aneurysm neck, depth of aneurysm, aspect ratio, non- sphericity index, surface Zernike moment invariants, volume Zernike moment invariants, vessel diameter or parent vessels (one per opening)) Attributes: Audit trail: (append to input audit trail of M_MA) Name; Date; Format; software module version; software module operator
Step 3: Haemodynamic Analysis Chain
The purpose of the haemodynamic analysis is to reduce the aneurysm flow conditions to a set of meaningful descriptors representing it. These descriptors are expected to facilitate the finding of statistical associations that would help understanding the natural history of the analysed aneurysm and eventually the risks of available treatments.
The haemodynamic descriptors are extracted from two complementary haemodynamic analyses: a global one and a local one, with an optional unidirectional coupling between them. The global one is based on a one-dimensional model of the human systemic circulation, including the main arteries of a complete circle of Willis, and predicts flow rate and pressure waveforms at predefined points. The local analysis uses the full three-dimensional geometry near the region of interest, obtained by clipping the three-dimensional geometry at appropriate places.
Step 3.1: Boundary Conditions
As no patient-specific measurements of flow properties at the openings defined by the clipping are generally available, the results of the one-dimensional global analysis will be used to obtain boundary conditions for the local three-dimensional analysis. Using the skeletonised representation of the three-dimensional vasculature in the region of interest
Page 42 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
calculated during the vascular geometry extraction stage, the operator manually defines perpendicular clipping planes and links the appropriate nodes of the one-dimensional circulation model to the corresponding points of the three-dimensional inlet and outlet boundaries, thus defining the boundary conditions for the three-dimensional model. Input Data Processing Step Output Data
1. G Analyst specifies the 1. GLOB1D (geometrical Source: VPH-Share mesh correspondences between the and physical properties and editing atomic service openings of the corrected connectivity of the 1D Format: Surface mesh (VTK) geometry and their equivalent model) Attributes: G audit trail locations in the 1D model Source: VPH-Share Units: meters This is done in the VPH-Share boundary conditions setting boundary condition setting atomic service 2. SKEL atomic service. Format: text Source: VPH-Share Attributes: Audit trail: skeletonisation atomic The boundary conditions and (append to input G trail) service their location in the geometric Name; Date; Format; Format: VTK model are saved to a named software module version; Attributes: SKEL audit trail storage location and the software module operator Units: meters Patient Avatar is updated accordingly.
Step 3.2: Haemodynamic Pre‐processing
To tackle the rise and fall of simulation applications, or the incompatibilities between versions, or the need of changing the parameters to be extracted, an application-neutral representation of the biomechanical problem is specified. This objective is accomplished by the specification of an Abstract Problem Description (APD). As a result, APDs enable the long-term and condensed storage of all simulations.
Despite the high-level nature of APDs, they contain or reference all information needed to generate input for any concrete simulation application run computing the analysis. There could be different runs using different applications for the same analysis, which should yield the ‘same’ results (up to some limit of accuracy). Sets of different runs could be used for verification of the solver-independence of results.
The conversion of an APD into a concrete simulation input and the subsequent run is, in principle, a completely automatic task, as the APD contained all relevant information; all necessary pieces of data needing human intervention are generated and stored before creating the APD. In practice, the feasibility of automation is certainly dependent on the application; in the case of @neurIST, we fully automated this step for the supported simulation packages. Exceptions to this rule are some qualitative characterisations that inevitably required human intervention.
Page 43 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Input Data Processing Step Output Data
1. G The VPH-Share 1. HD_APD (abstract Source: VPH-Share mesh haemodynamic pre-processing problem description for editing atomic service atomic service automatically haemodynamics, including Format: Surface mesh (VTK) generates the abstract problem cut locations, neck Attributes: G audit trail description for the locations, aneurysm list, Units: meters haemodynamic analysis to be boundary conditions, performed. material properties, solution 2. GLOB1D instructions) Source: VPH-Share Analyst selects the flow solver Source: VPH-Share HD boundary conditions setting and volumetric meshing pre-processing atomic atomic service software, and the VPH-Share service Format: text haemodynamic pre-processing Format: XML + DB entries Attributes: GLOB1D audit atomic service converts the Attributes: Audit trail: trail APD into the specific format (append to input GLOB1D of the selected flow solver and trail) Name; Date; Format; volumetric meshing software. software module version; software module operator The Abstract Problem Description is saved to a 2. Volumetric meshing named storage location and software configuration file the Patient Avatar is updated Source: VPH-Share HD accordingly. pre-processing atomic service Format: meshing software specific
3. Flow solver software configuration file Source: VPH-Share HD pre-processing atomic service Format: flow solver specific
4. Post-processing software configuration file Source: VPH-Share HD pre-processing module Format: post-processing flow solver specific
Step 3.3: Volumetric Mesh Generation
The flow solver needs an unstructured three-dimensional mesh of the vasculature volume. Meshes will be generated by the ANSYS ICEM 3D (Ansys Inc.). The mesh generator will label the aneurysmal interior in an automatic manner.
Page 44 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Input Data Processing Step Output Data
1. Volumetric meshing An external call to the 1. VOL_MESH software configuration file volumetric meshing software (volumetric mesh) Source: VPH-Share HD pre- is triggered. Source: VPH-Share processing atomic service volumetric mesh generation Format: meshing software The VPH-Share volumetric atomic service specific mesh generation atomic Format: meshing software service takes the resulting specific mesh of the meshing software and it is saved to a named storage location and the Patient Avatar is updated accordingly.
Step 3.4: Flow Simulation
In @neurIST, the transient blood flow was modelled by the Navier–Stokes equations under the assumption of rigid walls and a simple Newtonian rheology model with blood density of 1060 kg m3 and viscosity of 0.0035 Pa s.
The production runs will be performed using a commercial three-dimensional flow solver ANSYS CFX (Ansys Inc., Canonsburg, PA, USA), which is a finite volume computational fluid dynamics (CFD) code solving for the Navier-Stokes flow equations across an unstructured three-dimensional mesh of the vasculature volume. Input Data Processing Step Output Data
1. Flow solver software An external call to the flow 1. RES_CFX (flow configuration file solver software is triggered. simulation) Source: VPH-Share HD pre- The VPH-Share flow Source: VPH-Share flow processing atomic service simulation atomic service simulation atomic service Format: flow solver specific takes the resulting flow Format: flow solver specific solution from the flow solver and it is saved to a named storage location and the Patient Avatar is updated accordingly.
Step 3.5: Flow Simulation Post‐processing
The set of qualitative and quantitative descriptors (candidate risk factors) will be extracted from the flow solution automatically, except a few qualitative ones such as flow stability and intra-aneurysmal flow type requiring expert judgement.
Quantitative volumetric measures are performed within the aneurysm and at the neck. These include the maximum and mean velocities defined at peak systole and averaged over the cardiac cycle. Similarly, other measures are computed on the model surface, including areas of elevated pressure, impingement jet location, maximum static pressure on the wall at peak
Page 45 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
systole and the wall shear stress and derivates such as the oscillatory shear index. Some of these measures are highly dependent on the location of the aneurysm neck. Input Data Processing Step Output Data
1. RES_CFX (flow An external call to the flow 1. RES_HD (results of simulation) post-processing software is haemodynamic analysis) Source: VPH-Share flow triggered. Most of the Source: VPH-Share post- simulation atomic service haemodynamic descriptors are processing atomic service Format: flow solver specific automatically computed from Format: DB entries, XML the flow solution. Only a few Attributes: Audit trail: 2. Post-processing software ones need from the analyst (append to input G trail) configuration file intervention. Name; Date; Format; Source: VPH-Share HD pre- software module version; processing atomic service The VPH-Share flow software module operator; Format: post-processing flow simulation post-processing Skeletonisation algorithm solver specific atomic service takes the settings computed descriptors and they Units: SI units 3. HD_APD are saved to a named storage Source: VPH-Share HD pre- location and the Patient Avatar processing atomic service is updated accordingly. Format: XML + DB entries Attributes: HD_APD audit trail
5.1.4 Towards an @neurIST Patient Avatar
Such granular descriptions of the @neurIST workflow elements have revealed that there are quite a few clinically significant data items required to execute all of parts of the workflow. The process of characterising the @neurIST workflow has revealed the following clinical data requirements:
Patient Demographic Data Personal & Social History Fitness and Lifestyle Employment Details Vital Signs Heart Rate Blood Pressure Respiration Body Temperature Substance Use Alcohol Tobacco Caffeine Aneurysm Related Health Event Supporting Risk Factors Specimens (Blood, Tissue)
Page 46 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Medications (Contraceptives, Blood Thinning Agents) Aneurysm Imaging Study Other Imaging Details
The data items or concepts described above represents an overview of the categories of patient specific data. To constitute and fully descriptive @neurIST Patient Avatar, these categories need to be further expounded in increasing detail, along with unambiguous clinical terminologies and vocabularies. The existence/non-existence of a particular concept within the avatar does not mean that the data is mandatory/not required, but rather it represents the minimum ideal data requirements for the workflow. Some data items may also not routinely be collected as part of the project, and hence will require data derivation procedures to estimate physiological averages from patient phenotypes. Such missing data items could also be used to inform data providers to expose such relevant data items as part of the data collection procedures within future projects. As part of this document, we have attempted to create an initial first draft of an @neurIST Patient Avatar that collects all the necessary clinical data into a unified format. See Annex 5. We have used the openEHR standard described earlier as a vehicle to create a unified record of all the clinical information most likely relevant to the workflow as inputs, or associated outputs to help aid in diagnostic, simulation or post-processing activities. This is, by no means intended to be a final description of a @neurIST Patient Avatar, and we expect the avatar to evolve as the project progresses.
5.1.5 Legal/Ethical/Security Constraints
Relevant ethical and legal clauses collected, as part of agreements and consents within the @neurIST project will used to create data sharing agreements between the @neurIST project and VPH-Share. The @neurIST project will ensure that all data sharing activities will conform to the data sharing agreements and protocols developed specifically for @neurIST- VPH-Share data exposure. As per the description of work, the @neurIST project plans to expose relevant anonymised datasets within the VPH-Share consortium by Year 2, selected and extended release to the VPH community by Year 3 and public release by Year 4, subject to confirmation that the patient information sheets and consent forms support this process. Any necessary further communication with the relevant Research Ethics Committees (RECs) will take place in coming months.
Although not directly concerned with the ethical process, VPH-Share is strongly concerned with the governance process. 5.2 euHeart Workflow Information Model
Cardiovascular diseases (CVD) have a major impact on U.K. society in terms of global mortality, morbidity and healthcare costs. Developments in theoretical approaches and computational tools can provide new insights into the genesis and evolution of these diseases. There is a potential to enhance the management of CVD through a better understanding and quantification of physiological processes and variables.
Page 47 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Brachial artery blood pressure is a well-established risk factor and prognostic marker for several CVD diseases. While assessment of central pressure (either by direct invasive or indirect peripheral measures) has yielded important insights into the mechanics of the cardiovascular system in health and disease, current techniques remain limited. Specifically they typically quantify pressure at only a single, often ill defined, region of interest at a time, and do not fully capture the entire pressure field.
5.2.1 Overview of Key Workflow Elements
In this context the pressure estimation workflow provides the ability to non-invasively image the spatiotemporal variation of pressure. This represents a fundamental advance that in turn is likely to yield important insights into the mechanisms of cardiovascular physiology and pathology, and to provide biomarkers for future individualised cardiovascular risk assessment in a variety of disease states.
Figure 12: Overview of the Pressure Estimation Workflow
In a nutshell (see Figure 12), this workflow is depicted to start from the top left and proceeds clockwise (1) cleans a specialised dynamic set of images from the patient, (2) builds a computational mesh, (3) solves a constitutive equation in order to obtain the map of regional distribution of pressure, which is afterwards (4) post-processed to extract clinical meaningful indexes.
The remainder of this section: places the euHeart workflow in the context of the VPH-Share architecture (5.2.2); presents a detailed explanation of each of these four key steps (5.2.3);
Page 48 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
defines the euHeart Patient Avatar (5.2.4); describes alternative methodologies and data sources to extract similar pressure diagnostic information (5.2.5); and discussed the legal, ethical and security constraints (5.2.6).
5.2.2 VPH‐Share Architectural Context
VPH-Share is primarily an infrastructure project that aims to serve the four flagship workflows in the first instance. WP2, WP3, WP4 and WP6 aims to develop tools and technologies that will enable the flagship workflow refactor tools and services into the tool and data-sharing environment created. The euHeart workflow aims to repackage and deliver a few key applications as web services for consumption by the VPH community. They will also be augmented with auxiliary data (e.g. template meshes) required by the web services. It will also deliver key clinical anonymised datasets collected as part of the euHeart project. Each key workflow element described below will form part or full ‘atomic’ web services that will be delivered as deliverables to the VPH-Share infrastructure.
5.2.3 Key Workflow Elements
Step 1: Data Retrieval
Phase Contrast MRI is a set of four acquisitions that enable the measurement of flow velocity, with its 3 spatial components. Each MRI acquisition results in two components, magnitude and phase. A reference acquisition is compared to 3 phase encoded datasets corresponding to the 3 spatial directions of the velocity vector (x, y and z).
In this step of the workflow the clinical case of interest is selected and retrieved. The number of image series, and the number of frames per heart cycle, depends on the manufacturer and acquisition protocol. The main parameter during acquisition is the Venc, the Velocity Encoded, which is the maximum velocity that the phase encoding is able to capture without aliasing. For further details about acquisition of these sequences, please see Bock et al. [37].
Step 2: Image Processing: Velocity Calculation
This step in the workflow is responsible for a pre-processing of the image data in order to remove noise and artefacts in the image, and to calculate the velocity at each voxel of the image space. Sets of sub-steps are detailed next. All of them are performed with a research tool called Velomap (Bock [38]), a screenshot is provided in Figure 13.
Page 49 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Figure 13: Velomap Tool, showing selected processing options [38]
Due to the complex nature of the output data of this step (vectors of velocity located at every point of the space in a 3D volume of data), the software for advanced visualisation Ensight is adopted. This program has a proprietary format to describe geometries, fields, etc.. The complete set of files that will be the output of this step is composed by:
.case file: description of the complete set of files, and the timing of the frames of the sequence. .geo file: description of the geometry, of the box of voxel locations. .velocity files: a set of files, one per time frame, containing the description of the velocity at each voxel location. .magnitude files: a set of files, one per time frame, containing the grayscale level of each voxel.
Step 2.1: Noise Filtering Input Data Processing Step Output Data
1. PC-MRI data The Velomap tool is used 1. Filtered PC-MRI Format: DICOM to filter and remove the Format: DICOM noise of the data.
Step 2.2: Eddy Current Correction Input Data Processing Step Output Data
1. PC-MRI data The Velomap tool is used 1. Filtered PC-MRI Format: DICOM to estimate the location of Format: DICOM static tissue, the distribution of the Eddy currents, and its removal.
Page 50 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Step 2.3: Anti‐aliasing Input Data Processing Step Output Data
1. PC-MRI data The Velomap tool is used 1. Filtered PC-MRI Format: DICOM to locate and correct Format: DICOM aliasing of phase encoded velocity values.
Step 2.4: Velocity Calculation Input Data Processing Step Output Data
1. PC-MRI data The Velomap tool is used 1. Case Format: DICOM to calculate the velocity Format: EnSight field from the differences in phase between the reference and the 3 encoded acquisitions, once they have been filtered.
Step 3: Mesh Construction
A hexahedral regular rectangular mesh with cubic Lagrange interpolation functions is built from the geometric domain described by the Ensight files. Each voxel of the image space is a control point of the mesh, and therefore each element has a size of 3x3x3 voxels. Input Data Processing Step Output Data
1. Ensight geo file A simple programme is 1. Mesh Format: ensight (.geo) used to generate a Format: c-Heart Units: mm hexahedral mesh from the Units: mm location of the voxels.
Step 4: Simulation
A simulation engine reads the velocity data and the computational mesh, and solves the Pressure Poisson Equation, obtaining the maps of pressure differences in the complete spatial domain, following the methods described in Krittian et al. [39]. Input Data Processing Step Output Data
1. Ensight files Calculation of the map of 1. Pressure Format: ensight pressure differences. Format: Ensight Units: KPa 2. Mesh Format: c-Heart
Page 51 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Step 5: Post‐processing
The pressure maps are post-processed with the concatenation of a set of manual or automatic sub-tasks, as described next.
Step 4.1: Segmentation of the Aorta
The definition of the location and extents of the aorta is made from the velocity data itself, from the Ensight files. The velocity magnitude in each voxel is averaged through the sequence, and this image is semi-automatically segmented using ITK-Snap (http://www.itksnap.org). Input Data Processing Step Output Data
1. Ensight files Calculation of the map of 1. Binary mask Format: Ensight pressure differences. Format: VTK
Step 4.2: Extraction of the Centreline of the Aorta
The skeleton of the aorta binary mask is obtained, and a spline line is fitted to the points. This is done in Matlab, using the functionality of the Gerardus library14. Input Data Processing Step Output Data
1. Aorta mask Calculation of the map of 1. Centerline Format: VTK pressure differences. Format: matlab
Step 4.3: Calculation of Average Pressures
The skeleton of the aorta is used to define a set of perpendicular planes to that line, and disks of 1 cm or radius are used to sample the volume. Linear interpolation is used to calculate the pressure at those samples, and the mean and standard deviation of pressure is obtained in each disk. This is the way pressure transients are obtained, and it’s done for each frame. Input Data Processing Step Output Data
1. Pressure files Calculation of mean and 1. Pressure values Format: ensight standard deviation of Format: matlab Units: KPa pressure in a series of Units: KPa disks perpendicular to the 2. Geometry files aorta. Format: ensight Units: mm
14 http://code.google.com/p/gerardus/
Page 52 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
3. Aorta centerline Format: matlab Units: mm
Figure 14: Spatio-temporal map of pressure differences
Step 4.4: Report Preparation The concatenation of the pressure transients in the different frames compose what is called a spatio-temporal map of pressure differences, like the one illustrated in Figure 14.
Input Data Processing Step Output Data
1. Ensight files Calculation of the map of 1. Binary mask Format: Ensight pressure differences. Format: VTK
5.2.4 Towards an euHeart Patient Avatar
Such granular descriptions of the euHeart workflow elements have revealed that there are quite a few clinically significant data items required to execute all of parts of the workflow. The process of characterising the euHeart workflow has revealed the following clinical data requirements:
Patient Demographic Data Personal & Social History Fitness and Lifestyle Employment Details Vital Signs Heart Rate Blood Pressure Respiration Body Temperature Substance Use Alcohol Tobacco
Page 53 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Caffeine Baseline History Cardiac Health Event Cardiac Imaging Study Lab Tests Urine Blood ECG Recording Hand Grip Strength Pulmonary Function Medication History Imaging Details
The data items or concepts described above represents an overview of the categories of patient specific data. To constitute and fully descriptive euHeart Patient Avatar, these categories need to be further expounded in increasing detail, along with unambiguous clinical terminologies and vocabularies. The existence/non-existence of a particular concept within the avatar does not mean that the data is mandatory/not required, but rather it represents the minimum ideal data requirements for the workflow. Some data items may also not routinely be collected as part of the project, and hence will require data derivation procedures to estimate physiological averages from patient phenotypes. Such missing data items could also be used to inform data providers to expose such relevant data items as part of the data collection procedures within future projects. As part of this document, we have attempted to create an initial first draft of a euHeart Patient Avatar that collects all the necessary clinical data into a unified format, see Annex 6. We have used the openEHR standard described earlier as a vehicle to create a unified record of all the clinical information most likely relevant to the workflow as inputs, or associated outputs to help aid in diagnostic, simulation or post-processing activities. This is, by no means intended to be a final description of a euHeart Patient Avatar, and we expect the Avatar to evolve as the project progresses.
5.2.5 Alternative Data Sources
Pressure differences can also be estimated from two other alternative methodologies: echography and catheterisation. The echo measurements assume and characterise a simplified Bernoulli effect, and the catheterisation is considered the gold standard technique. More insights into the differences between the three alternatives are provided in Bock et al. [37].
Therefore, it would be quite interesting to have patient information related to the pressure and cardiovascular health condition:
Recordings of systemic pressure (brachial pressure). Any ultrasound exploration of the vessels or catheterisation with pressure sensors, usually done in order to characterise a pressure drop. Any alternative measurement of blood velocity, by ultrasound for example with a compounded technique. Any alternative measurement of blood acceleration, by other specialised sequences in MRI.
Page 54 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
5.2.6 Legal/Ethical/Security Constraints
Relevant ethical and legal clauses, as part of agreements and consents collected within the euHeart project will used to create data sharing agreements between the euHeart project and VPH-Share. The euHeart project will ensure that all data sharing activities will conform to the data sharing agreements and protocols developed specifically for euHeart VPH-Share data exposure. As per the description of work, the euHeart project plans to expose relevant anonymised datasets within the VPH-Share consortium by Year 2, selected and extended release to the VPH community by Year 3 and public release by Year 4, subject to confirmation that the patient information sheets and consent forms support this process. Any necessary further communication with the relevant Research Ethics Committees (RECs) will take place in coming months.
Although not directly concerned with the ethical process, VPH-Share is strongly concerned with the governance process. 5.3 ViroLab Workflow Information Model
This section describes the Workflow Information Model (WIM) as used by the ViroLab flagship workflow of the VPH-Share project. It details the technologies used for the services as well as the individual resources and data and interchange formats and media types. The use of the word “workflow” is a slight misnomer within the ViroLab project as the project aims to expose the multitude of applications within the VPH-Share project as atomic web-services. Each application may be combined in multiple ways to create a patient specific workflow based on the measured information and the amount of inference required.
5.3.1 Overview of Key Workflow Elements
The Virolab workbench has been modularised and tailored as a collection of web services in preparation for deployment on the VPH-Share cloud platform. Each web service will expose resources in a RESTful way, which allows the application to be stateless. The Resources are combined into a number of web-based tools for use by clinicians or scientists performing virological research.
Each of the applications from the Virolab workbench has been analysed to identify potential data and data sources that may be relevant for each workflow.
5.3.2 Architectural Context
VPH-Share is primarily an infrastructure project that aims to serve the four flagship workflows in the first instance. WP2, WP3, WP4 and WP6 aims to develop tools and technologies that will enable the flagship workflow refactor tools and services into the tool and data-sharing environment created. The ViroLab workflow aims to repackage and deliver a few key applications as web services for consumption by the VPH community. It will also deliver key clinical anonymised datasets collected as part of the ViroLab project. Each key workflow element described below will form part or full ‘atomic’ web services that will be delivered as deliverables to the VPH-Share infrastructure.
Page 55 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
5.3.2.1 Web Services and Resources
Each of our Web Services exposes a number of resources in a RESTful way. The RESTful approach facilitates building scientific workflows in a modular and stateless fashion.
Resources are combined into a number of web-based tools for use by clinicians or scientists performing virological research.
5.3.2.2 Data Exchange and Media Types
The ViroLab applications exposed as webservices will not be data intensive. Individual service calls typically exchange small amounts of structured data. However aggregate calls and database sweeps can lead to larger exchanges but this workflow does not need to exchange the large compound datasets like images, meshes and such required by other VPH- Share workflows.
For data exchange, the workflow uses JavaScript Object Notation (JSON). This semi- structured data representation had a number of useful advantages in the prototyping phase. It is lightweight, flexible, compositional and thus easily extensible, as well as being human readable. Other similar representations such as YAML or even S-expressions would also have been suitable, however JSON is widely used and many mutually compatible code libraries are available to translate it to and from native formats.
The workflow is now moving from prototype resources to a broader environment where the APIs for resources will need to be more formally specified, the need arises for schemata for the input and output formats. Several options present themselves. The project could retain JSON as the default media type and use JSON Schema to provide the contract for what JSON data is required for each application and how to interact with it. JSON Schema has currently the status of an expired IETF draft and existing implementations are sparse so the project is sceptical of both its future and its suitability. Another approach to writing schemata for JSON is Kwalify but its semantics are lacking.
The workflow could also opt for a more standardised schema approach such as XML Schema, RelaxNG. For the purposes of this document and of the project, unless otherwise indicated, all resources accept input and produce their output in a mutually agreed JSON format.
5.3.3 Key Workflow Elements
Comparative Drug Ranker
The Comparative Drug Ranker provides drug resistance interpretations for a given set of mutations based on several existing rule systems. Rule systems currently handled are:
ANRS Agence Nationale de Recherches sur le SIDA, France. HIVDB Stanford University HIV Drug Resistance Database, USA. Rega Rega Institute, Belgium.
Page 56 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Input is provided in the form of a list of mutations together with corresponding genome regions. Optionally, rule sets and corresponding versions may be indicated.
Output is presented as a ranking of drugs according to susceptibility or resistance to the mutations given. See Listing 1 (Annex 3) for sample output.
Literature Miner
The amount of biomedical literature regarding to HIV drug resistance is increasing so rapidly that it is becoming too labour intensive for experts to collect reliable drug resistance information in a convenient and effective manner. As a result, a significant amount of drug resistance data remains hidden in biomedical literature. Therefore there is a need for computational methods that automate parts of this process and that can assist in retrieving and updating causal relations between virus mutations and antiretroviral drugs from the literature.
The Literature Miner extracts and combines causal relations among mutations and drugs using a Causal Relation Extraction Inference Engine. The text retrieval component of the Causal Relation Extraction Inference Engine collects candidate abstracts from the PubMed database on the 23 drugs that are currently approved by the U.S. Food and Drug Administration (FDA) for antiretroviral therapy of HIV.
Discordance Imputer
A given set of mutations can lead to differing resistance interpretations by different rule systems. To gain insight into the rules responsible for such discordance the user may wish to consult the Discordance Imputer. The Discordance Imputer selects the rules responsible for the judgments’, infers their logical symmetric difference and presents the result.
Patient Comparator
A clinician may be interested in comparing a patient under treatment with other known patients who are carrying similar strains of HIV and their treatment records. The Patient Comparator is invoked through the appropriate web tool. In essence it intelligently performs a number of SQL queries based on mutation similarity metrics and returns a report on prevalence’s from the patient databases accessed.
Complex Network Visualiser
Twilight is an interactive graph visualisation service developed at the University of Amsterdam. The service can represent multiple, dynamic networks simultaneously, in which the connectivity between vertices changes over time. In particular it can present a simultaneous visualisation of a social contact network and a phylogenetic network allowing reciprocal inferences to be made.
This service is currently in development. Further information will be added at a later date.
Page 57 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Figure 15: Twilight visualisation tool showing clusters of HIV patients
Binding Affinity Calculator
The Binding Affinity Calculator is a service provided by our partners at UCL. Our Binding Affinity Calculator resource is merely a wrapper that accepts drug and mutation information and presents it to UCL’s service in their format.
Literature Base
The Literature Base is fed by the text retrieval component of the Causal Relation Extraction Inference Engine. The dates are stored in a SQL database. As an indication of the size of the Literature Base, we obtained 129,448 unique abstracts when the search was carried out in June, 2009. Among these collected abstracts there were 74,321 abstracts containing at least one relevant drug name in the body text, 9,651 abstracts contained HIV mutations, and 5,615 abstracts contained both drugs and mutations.
Bayesian Evidence Aggregator
Decision making with incomplete evidence is a difficult but frequently occurring medical dilemma. A number of methods are available which when judiciously applied lead to a reasonable structure for decision making in clinical situations with incomplete evidence and even with sources evidence, which are inconsistent.
Information, data and evidence from the component sources and resources of the ViroLab workflow as well as data from provenance need to be combined to provide coherent judgments on drug-susceptibility. In order to aggregate evidence from the various sources and resources, the clinician may benefit from assistance in combining the relative evidential strengths.
In order to provide coherent judgments taking into account evidence from literature, rule sets, modelling and simulation will need to combine a number of kinds of knowledge, categorised by Shortliffe and Pagan [40] as:
Page 58 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
knowledge derived from data analysis (numerical or statistical) judgemental or empirical subjective knowledge common sense or scientific knowledge strategic knowledge or procedural knowledge
The approach will be to use Bayesian hierarchical modelling to make predictive distributions in the presence of uncertainty. The full chain of analysis will combine Bayesian hierarchical modelling with probabilistic decision analysis based on utility attribution and/or multi- objective optimisation of such quantities as cost, chance and duration of survival or quality- adjusted life years.
Rule Maintenance Engine
The Rule Maintenance Engine gathers HIV drug resistance data in the form of rules and scores and stores them in a relational database, keeping the rulebase up to date as newer versions appear. Data are retrieved from published XML & HTML formats. All conversions are made explicit (declarative, not in imperative code) for provenance purposes. Rules are stored in raw form and in cleaned form. Cleaning ensures (intra- and inter-) ruleset consistency. Versioning is maintained. Each version of each ruleset is stored and available for consultation and comparison. Links should be established between articles referred to in rules and abstracts in PubMed.
This component runs autonomously offline. The rulebase maintainer interacts with the rulebase to check consistency and integrity and makes adjustments as necessary to maintain them.
Rule Base
The HIV drug resistance rulebase is a SQL relational database containing rules relating HIV mutations and resistance to antiretroviral drugs.
Patient Database
Treatment guidelines recommend carrying out a genotypic resistance test as soon as patients are diagnosed with HIV-1. As a consequence, substantial numbers of HIV-1 sequences are available. We have access to large numbers of sequences through databases accessible through the projects EuResist, SPREAD (>3,000 sequences), ARCA (>10,000), and ViroLab directly (>3,000) as well as directly through a number of participating hospitals (IrsiCaixa, UCSC, KUL & EMC).
Since policies regarding patient records and treatment differ, the available data on patient can vary a great deal. Typically, but not universally, patient data will include:
Demographics Treatment information Sequence id Viral subtype Sequence calendar year
Page 59 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Patient’s gender Patient’s age Mode of HIV transmission: men having sex with men (MSM), hetero-sexual, intravenous drug user (IDU), blood products, other/unknown Country of origin Zone of residence Date of first test HIV positive test Antiretroviral therapy (ART) status (ART-experienced/ART-naive), Seroconversion year (median time between last HIV negative test date and first HIV positive test date) Calendar year of first HIV positive test and of first available an- tiretroviral therapy Plasma HIV-RNA load at viral sequencing time CD4+ cell count Presence of resistance mutations for nucleoside-tide/non-nucleoside reverse transcriptase inhibitors (NRTI and nNRTI) and protease in- hibitors (PI) in the HIV sequence RNA sequence information encompassed the HIV pol gene region, covering the whole protease and most of the reverse transcriptase gene.
Inferring missing data, particularly on social and sexual contact networks, and its potential influence on drug resistance will be a valuable contribution of the ViroLab VPH-Share workflow. Specific questions that can be addressed are:
1. Onward transmission of drug resistant variants among treatment naive patients and the extent by which onward transmission plays a role in the spread of HIV. 2. Phylogenetic networks as a proxy for transmission networks.
5.3.3.1 Data Formats
ASI
Causal relations between HIV mutations and the resulting resistance to drugs are expressed as rules in the Algorithm Specification Interface language [41]. See Listing 2 (Annex 3) for an example drug resistance rule expressed in ASI.
ASI is an XML language specified by an XML Document Type Definition (DTD). However the rule sets as expressed in ASI have never been entirely faithful to the DTD and this situation has slipped further as changes have crept into the language used to express rule sets which have not been folded back into the specification.
Mutations
Mutations are indicated as amino acids, deletions or insertions present at positions on regions of the HIV genome. Amino acids are represented by their standard 1-letter abbreviations. A mutation is uniquely specified by a region (e.g. protease), a position (an integer) and a standard one-letter abbreviation for an amino acid (e.g. C for cysteine). An insertion or deletion is indicated by i or d respectively. The mutation protease 54G indicate the presence of glycene instead of isoleucine at position 54 of the protease region.
Page 60 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
The regions in question are:
Protease (Retropepsin) (EC 3.4.23.16) PQVTLWQRPLVTIKIGGQLKEALLDTGADDTVLEEMSLPGRWKPKMIGGIGGFI KVRQYDQILIEICGHKAIGTVLVGPTPVNIIGRNLLTQIGCTLNF
• Reverse Transcriptase (EC 2.7.7.49) PISPIETVPVKLKPGMDGPKVKQWPLTEEKIKALVEICTEMEKEGKISKIGPEN PYNTPVFAIKKKDSTKWRKLVDFRELNKRTQDFWEVQLGIPHPAGLKKKKSVTV LDVGDAYFSVPLDEDFRKYTAFTIPSINNETPGIRYQYNVLPQGWKGSPAIFQS SMTKILEPFRKQNPDIVIYQYMDDLYVGSDLEIGQHRTKIEELRQHLLRWGLTT PDKKHQKEPPFLWMGYELHPDKWTVQPIVLPEKDSWTVNDIQKLVGKLNWASQI YPGIKVRQLCKLLRGTKALTEVIPLTEEAELELAENREILKEPVHGVYYDPSKD LIAEIQKQGQGQWTYQIYQEPFKNLKTGKYARMRGAHTNDVKQLTEAVQKITTE SIVIWGKTPKFKLPIQKETWETWWTEYWQATWIPEWEFVNTPPLVKLWYQLEKE PIVGAETF
• Integrase (EC 2.7.7) FLDGIDKAQDEHEKYHSNWRAMASDFNLPPVVAKEIVASCDKCQLKGEAMHGQV DCSPGIWQLDCTHLEGKVILVAVHVASGYIEAEVIPAETGQETAYFLLKLAGRW PVKTIHTDNGSNFTGATVRAACWWAGIKQEFGIPYNPQSQGVVESMNKELKKII GQVRDQAEHLKTAVQMAVFIHNFKRKGGIGGYSAGERIVDIIATDIQTKELQKQ ITKIQNFRVYYRDSRNPLWKGPAKLLWKGEGAVVIQDNSDIKVVPRRKAKIIRD YGKQMAGDDCVASRQDED
HIV Inhibitor Drugs
The following tables list the licensed (at time of writing) antiretroviral drugs for the treatment of HIV by category. Generic names, brand names and customary abbreviations are given. The tables are adapted from the Stanford University HIV Drug Resistance Database [42].
Protease Inhibitors (PIs) Generic Name Brand Name Abbreviation
tipranavir/r Aptivus TPV/r indinavir/r Crixivan IDV/r saquinavir/r Invirase SQV/r lopinavir/r Kaletra LPV/r fosamprenavir/r Lexiva FPV/r atazanavir/r Reyataz ATV/r nelfinavir Viracept NFV darunavir/r Prezista DRV/r
Page 61 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Nucleoside Reverse Transcriptase Inhibitors (NRTIs) Generic Name Brand Name Abbreviation
emtricitabine Emtriva FTC lamivudine Epivir 3TC zidovudine Retrovir AZT didanosine Videx ddI tenofovir Viread TDF stavudine Zerit d4T abacavir Ziagen ABC
Non-Nucleoside Reverse Transcriptase Inhibitors (NNRTIs) Generic Name Brand Name Abbreviation
delavirdine Rescriptor DLV efavirenz Sustiva EFV etravirine Intelence ETR nevirapine Viramune NVP
Integrase Inhibitors Generic Name Brand Name Abbreviation
raltegravir Isentress RAL elvitegravir EVG
JSON Prototyping Formats
As described earlier, JSON was used for data exchange during the proto-typing phase for its flexibility and extensibility. No schemata were given for the formats used, merely semi- formal descriptions. Here is an example of such a semi-formal description for the output of the Literature Miner.
The results of the literature mining service are written in a JSON document with the following structure:
1. The document is a JSON object “result” with the following properties: “query” (string) “total” (string) “literature” (array) 2. result.query: mutations entered as an input 3. result.total: contains the number of literature asked 4. result.literature: list of literature
Page 62 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
5. Each item in result.literature is a JSON object "literature" with the following structure: The properties of the object are: i. "title" (string) ii. "publication_id" (string) iii. "query" (string) iv. "sentences" (array) literature.title: literature title literature.publication_id: PubMed ID literature.query: mutations used to retrieve the literature literature.sentences: list of sentences in the abstract. Each item in the array also contains information about drugs, mutations, and relations correspond to the sentence. Each item in literature.sentences is a JSON object "sentence" with the following structure: i. The properties of the object are: 1. "sentence" (string) 2. "drugs" (array) 3. "mutations" (array) 4. "relations" (array) 5. "query_mutations" (array) ii. sentence.sentence: a sentence in the abstract iii. sentence.drugs: list of drugs (string) mentioned in the sentence iv. sentence.mutations: list of mutations (string) mentioned in the sentence v. sentence.relations: list of drug-mutation relations (string) mentioned in the sentence vi. sentence.query_mutations: list of drugs (string) that are mentioned in the sentence and also in the query (literature.query) The full abstract of the literature can be constructed by concatenating the "sentence" property of each item of literature.sentences. The order of items corresponds to the order of the sentence in the full abstract.
As examples of the JSON formats used in the prototyping phase, we include in Listing 1 (Annex 3) a partial sample output of the Comparative Drug Ranker and in Listing 3 (Annex 3) a partial sample output of the Literature Miner.
5.3.4 Towards a ViroLab Patient Avatar
Such granular descriptions of the ViroLab workflow elements have revealed that there are quite a few clinically significant data items required to execute all of parts of the workflow. The process of characterising the ViroLab workflow has revealed the following clinical data requirements:
Patient Demographic Data Personal & Social History
Page 63 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Fitness and Lifestyle Sexual Health Employment Details Vital Signs Heart Rate Blood Pressure Respiration Body Temperature Substance Use Alcohol Tobacco Caffeine Specimens DNA Sequence
The data items or concepts described above represents an overview of the categories of patient specific data. To constitute and fully descriptive ViroLab Patient Avatar, these categories need to be further expounded in increasing detail, along with unambiguous clinical terminologies and vocabularies. The existence/non-existence of a particular concept within the avatar, does not mean that the data is mandatory/not required, but rather it represents the minimum ideal data requirements for the workflow. Some data items may also not routinely be collected as part of the project, and hence will require data derivation procedures to estimate physiological averages from patient phenotypes. Such missing data items could also be used to inform data providers to expose such relevant data items as part of the data collection procedures within future projects. As part of this document, we have attempted to create an initial first draft of a ViroLab patient avatar that collects all the necessary clinical data into a unified format. See Annex 7. We have used the openEHR standard described earlier as a vehicle to create a unified record of all the clinical information most likely relevant to the workflow as inputs, or associated outputs to help aid in diagnostic, simulation or post-processing activities. This is, by no means intended to be a final description of a ViroLab patient avatar, and we expect the avatar to evolve as the project progresses.
5.3.5 Alternative Data Sources
Inferring missing data, particularly on social and sexual contact networks, and its potential influence on drug resistance will be a valuable contribution of the ViroLab VPH-Share workflow. Specific questions that can be addressed are:
Onward transmission of drug resistant variants among treatment naive patients and the extent by which onward transmission plays a role in the spread of HIV. Phylogenetic networks as a proxy for transmission networks.
5.3.6 Legal/Ethical/Security Constraints
Relevant ethical and legal clauses, as part of agreements and consents collected within the ViroLab project will used to create data sharing agreements between the ViroLab project and VPH-Share. The ViroLab project will ensure that all data sharing activities will conform to
Page 64 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
the data sharing agreements and protocols developed specifically for ViroLab VPH-Share data exposure. As per the description of work, the ViroLab project plans to expose relevant anonymised datasets within the VPH-Share consortium by Year 2, selected and extended release to the VPH community by Year 3 and public release by Year 4, subject to confirmation that the patient information sheets and consent forms support this process. Any necessary further communication with the relevant Research Ethics Committees (RECs) will take place in coming months.
Although not directly concerned with the ethical process, VPH-Share is strongly concerned with the governance process. 5.4 VPHOP Workflow Information Model
The VPHOP workflow, illustrated in the below figures, produces a numerical characterisation of the risk of fracture at a given skeletal location (e.g. proximal femur). The VPHOP workflow may be viewed from different perspectives, all relevant to its deployment in VPH- Share.
From the clinician perspective, the workflow is that depicted in Figure 16. From the modelling perspective, all the relevant information is contained in the “personalised risk estimate” boxes, which can be roughly exploded into the flowchart of Figure 17. From the architectural perspective (managing of data and control flows in a coherent IT framework) the workflow logic is that depicted in Figure 18.
Personalised Personalised High risk risk estimate treatment planning
At general Instrumental Medium Personalised risk diagnosis risk risk estimate High risk
Screening Referral interview Low risk
Not at Lifestyle Monitor every general risk modification All 2 years
Figure 16: Simplified VPHOP workflow (Clinical Perspective)
The VPHOP workflow is expected to be highly relevant in the context of Bone Fracture Risk prediction, since: (i) it is the first approach to fracture risk prediction completely based on patient information (i.e. not ranking risk based on comparisons with population based data); (ii) it will attempt to improve the current high misclassification errors: the epidemiology literature suggests that using T-score FRAX® (the current state of the art) with a cut off of
Page 65 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
3% on the risk of hip fracture, 50-55% of the fractures are captured15 while unfortunately, the other 50% is misclassified due to factors (bone response to complex loading conditions, neuromotor degradation, propensity to fall) that are completely neglected in FRAX, but thoroughly considered in VPHOP;
In the following paragraphs, a general overview of the overall modelling procedure is first given. Then, the workflow architecture is briefly described, VPHOP workflow. Finally, a complete workflow is described and details are given about each step of the workflow.
5.4.1 Overview of Key Workflow Elements
The main input to VPHOP workflow in its current incarnation consists of a medical image to detect bone shape and bone properties. This primary input is complemented by generic musculoskeletal data (e.g. from atlases) possibly scaled onto the patient to characterise the expected bone loading, and by parameters describing the patient status (e.g. general anthropometrics, lifestyle, pre- or post-menopausal condition, possible previous fractures or treatment for osteoporosis, level of bone cellular activity from blood essays, etc.). A focus of VPH-Share will be the exploitation of population data to infer those pieces of input not available as patient-specific. The output is a patient-specific, model-based estimate of the absolute risk of fracture (i.e. the risk of incurring in a fracture within a certain period, e.g. 10 years) based on the calculated strain levels in the bone tissue.
Figure 17: Simplified VPHOP workflow (modelling perspective)
The overall modelling procedure includes a pre-processing of the image data (segmentation, manual or semi-automatic virtual palpation, meshing, mapping of data from the diagnostic image grid onto the mesh,) to obtain bone shape, an estimate of bone mechanical properties, and muscle insertions and lines of action. The core of the process is the organ level model,
15 http://www.ncbi.nlm.nih.gov/pubmed/21723761
Page 66 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
that (i) describes the bone segment of interest in terms of continuum mechanics, (ii) takes boundary conditions from a multi body dynamics model describing the musculoskeletal system, (iii) may take anisotropic bone properties based on image texture analysis from a tissue level model, (iv) may consider an update of bone architecture and properties over time from a cell-level model, (v) obtains stresses and strains in the bone segment from a finite element or equivalent formulation, (vi) returns a risk of fracture.
The organ level model is personalised in terms of the bone anatomy and bone properties, since it is based on the patient’s image. The level of personalisation of the musculoskeletal, tissue and cellular models may be variable, depending on the input data available. The VPHOP workflow is still a live project and the presence and the level of completeness and integration of the tissue and cellular models transferred to VPH-Share still has to be defined, since their development relies on partners which are not part of VPH-Share consortium. Similarly, the coding of part of the VPHOP model in FieldML, as supported by VPH-Share, is still to be carefully evaluated.
5.4.2 VPH‐Share Architectural Context
The VPHOP hypermodel will be based on MAF (version MAF3) and will have bus architecture (as described in VPHOP deliverable D2.2; more details are expected in a forthcoming document describing the updated control flow). The MAF3 event bus will be used to dispatch the communication flow between modules. In Figure 18 the cyan hexagon represent core components, which provide services valid for all modules. Three core modules are important with respect to the end users:
The storage services, which allow the data cloud to be uploaded and replicated in those nodes where it is necessary all datasets; The application server, which will expose as web applications some hypermodel services; The Transformation services, which process datasets along the data flow, to ensure that they are properly formatted and organised, so to be used as inputs for the next module in the workflow.
Page 67 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Figure 18: VPHOP workflow (architectural prespective)
Virtual OsteoPorosis (VOP) and HypMonitor will run as end-user applications, communicating with the storage services and the application server for backend services.
Every component model is exposed to the bus via a wrapper, which standardise the communication (both data and control flows) between the proprietary applications that may be called (e.g. Ansys) and the rest of the hypermodel.
The Mechanical Turk interface makes it possible to include manual operations in the workflow, as if they were just additional component modules. Some Mechanical Turk modules simply provide a work list and the necessary data upload-download services, whereas for others, the end-user application can be fully integrated with it.
The VPHOP workflow in collaboration with WP2, WP3, WP4, WP6 aims to repackage and deliver a few key applications as web services for consumption by the VPH community. It will also deliver key clinical anonymised datasets collected as part of the VPHOP project. Each key workflow element described below will form part or full ‘atomic’ web services that will be delivered as deliverables to the VPH-Share infrastructure.
5.4.3 Key Workflow Elements
A description of the workflow and of the modules involved is provided below. This description is based on the current level of understanding, and might change during the early testing of the architecture, which is going to happen before February 2012.
Also, this description represent the ideal level of implementation having all VPHOP modules available, In VPH-Share, we might have to accept that some modules (i.e. tissue and remodelling) are not present or based only on a conceptual or rudimentary implementation. On the contrary, we may have available a full muscoloskeletal model rather than a database.
Page 68 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Last, some technical solutions such as the use of PCA modes to build a distance function in the organ and tissue-level databases, while theoretically viable, remain to be tested.
To the purpose of the schematic description, the VPHOP workflow of models and data can be itemised as follows:
Information Pre-processing Retrieve and store patient’s diagnostic image(s) and other patient parameters e.g. (age, height, weight, …) into a local repository in combination of an OpenClinica database
Organ-Level Processing Build a complete representation of bone 3D geometry Map muscle insertions and lines of action on bone geometry Generate an FE mesh of bone geometry Derive bone density (from diagnostic images) and map it on the FE mesh
Step 1: Information pre‐processing
Start workflow and Information pre-processing: the clinician submits the request for personalised risk estimate. Before he can do so all information included in the VPHOP clinical baseline have to be already logged in the OpenClinica database; in addition the imaging data have been already collected, and uploaded. The submission of the request initiates the VPHOP workflow.
Step 2: Organ‐level Processing
The organ-level information pre-processing step depends on the imaging modalities available for pre-processing.
Step 2.1: EOS/QT exam pre‐processing Input Data Processing Step Output Data
1. EOS data Analyst preforms the 1. 3D bone geometry Source: Local repository EOSppMT processing by Format: Mesh (.msh) Format: EOS performing the following steps: 2. Bone morphometry a. Download the EOS data Format: Text file b. Morph the bone geometry c. Morph the template mesh 3. Morphed mesh d. Upload the derived Format: Mesh (.msh) information to the OpenClinica Database 4. Principal component analysis (PCA) weights Format: Text file
5. Tissue Morphometry
Page 69 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Vector(TMV) Format: Text File Attributes: Volume Fraction only
Step 2.2: Clinical CT pre‐processing Input Data Processing Step Output Data
1. CT data Analyst preforms the 1. 3D bone geometry Source: Local repository CTppMT processing by Format: Mesh (.msh) Format: CT Scan performing the following steps: 2. Bone morphometry Format: Text file a. Download the CT data b. Segment CT 3. Morphed mesh c. Morph the template mesh Format: Mesh (.msh) d. Run Bonemat e. Upload the derived 4. Principal component information to the analysis (PCA) weights OpenClinica Database Format: Text file
5. Tissue Morphometry Vector(TMV) Format: Text File Attributes: Volume Fraction only
Step 2.3: XperCT pre‐processing Input Data Processing Step Output Data
1. XperCT data Analyst preforms the 1. 3D bone geometry Source: Local repository XperCTppMT processing by Format: Mesh (.msh) Format: XperCT performing the following steps: 2. Bone morphometry Format: Text file a. Download the XperCT data b. Segment XperCT 3. Morphed mesh c. Morph Template Mesh Format: Mesh (.msh) d. Run Bonemat (to be tested on XperCT) 4. Principal component e. Upload the derived analysis (PCA) weights information to the Format: Text file OpenClinica Database 5. Tissue Morphometry Vector (TMV) Format: Text File Attributes: Volume Fraction, DA, TbTh
Page 70 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Step 2.3: Query LoadingDB Input Data Processing Step Output Data
1. Patient Parameters Analyst queries the 1. Loading Spectrum Source: OpenClinica OpenClinica database for Format: Text File Database patient parameters e.g. (age, Format: key:value height, weight, …) and bone morphology measures 2. Bone Morphology Measures Analyst computes the loading Format: Text File spectrum
Analyst uploads the loading spectrum to the local repository
Step 2.4: Body‐Organ Boundary Conditions Input Data Processing Step Output Data
1. 3D bone Geometry Analyst morphs the loading 1. Morphed Mesh Format: Mesh (.msh) spectrum onto the bone Format: Mesh (.msh) geometry 2. Loading Spectrum 2. Insertion Maps Format: Text File Analyst computes the Format: Text File morphed mesh, insertion map and loads 3. Load Data Format: Text File Analyst uploads the resultant insertion maps and loads to the local repository.
Step 2.5: Query High‐ResolutionDB Input Data Processing Step Output Data
1. Tissue Morphometry Analyst searches the Best 1. Best Matching Tissue- Vector Matching Tissue-resolution resolution Volume Format: Text File Volume (BMTV) Format: Text File
2. Bone Morphometry Analyst computes Tissue 2. Tissue Morphometry Measures Mechanical Properties Vector Vector Format: Text File (TMPV) Format: Text File
3. PCA weights (anatomo- Analyst uploads BMTV_ID, 3. Tissue Mechanical densitometric morphing) TMV(full) and TMPV(t0)to Properties Vector Format: Text File the local repository. Format: Text File
Page 71 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Step 2.6: Run Organ‐Level Model Input Data Processing Step Output Data
1. Loading Spectrum Analyst runs the organ-level 1. Risk of Fracture Format: Text File model simulations Format: Text File
2. Morphed Mesh The simulations result in the 2. Displacement and Format: Mesh (.msh) calculation of Risk of Fracture Strain Fields (spectrum distribution, Format: Text File 3. Tissue Mechanical absolute metric) Properties Vector Format: Text File Analyst uploads Risk of Fracture at time zero (RFS(t0)), Displacement and Strain fields for selected load cases
Step 2.7: Run Bone Remodelling model Input Data Processing Step Output Data
1. Best Matching Tissue- Analyst runs the Bone Re- 1. Tissue Mechanical resolution Volume (volume, modelling step until t1 Properties Vector (t1, ttx) BC, Strain) Format: Text File Format: Text File The computations results in a new Tissue Mechanical 2. Patient Parameters Properties Vector (TMPV(t1, Format: Mesh (.msh) ttx)
3. Biomarkers Analyst uploads the Tissue Format: Text File Mechanical Properties Vector (TMPV(t1, ttx) to the local 3. Pharma Treatment repository Options (ttx) Format: Text File
Step 2.8: Re‐Run Organ‐level model Input Data Processing Step Output Data
1. Loading Spectrum Analyst re-runs the organ- 1. Risk of Fracture Format: Text File level model simulations Format: Text File
2. Morphed Mesh The simulations result in the 2. Displacement and Format: Mesh (.msh) calculation of Risk of Fracture Strain Fields (spectrum distribution, Format: Text File 3. Tissue Mechanical absolute metric) Properties Vector(t1, ttx)
Page 72 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Format: Text File Analyst uploads Risk of Fracture at time zero (RFS(t1, ttx)), Displacement and Strain fields for selected load cases for visualisation
Step 2.9: Generate Report Input Data Processing Step Output Data
1. Risk of Fracture Analyst loads the Risk of 1. Report Format: Text File Fracture and Displacement Format: PDF/Text and Strain Fields data into 2. Displacement and Strain InspectorMT along with Fields authorisation data Format: Text File The data is then automatically submitted to the clinical user
5.4.4 Towards a VPHOP Patient Avatar
Such granular descriptions of the VPHOP workflow elements have revealed that there are quite a few clinically significant data items required to execute all of parts of the workflow. The process of characterising the VPHOP workflow has revealed the following clinical data requirements:
Patient Demographic Data Personal & Social History Employment Details Fitness and Lifestyle Hand Grip Strength Vital Signs Heart Rate Blood Pressure Respiration Body Temperature Substance Use Alcohol Tobacco Calcium Caffeine Medical History Gynaecological Information Orthopaedic Health Event Bone Phenotype Imaging Study Other Imaging Details
Page 73 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
The data items or concepts described above represents an overview of the categories of patient specific data. To constitute and fully descriptive VPHOP Patient Avatar, these categories need to be further expounded in increasing detail, along with unambiguous clinical terminologies and vocabularies. The existence/non-existence of a particular concept within the avatar does not mean that the data is mandatory/not required, but rather it represents the minimum ideal data requirements for the workflow. Some data items may also not routinely be collected as part of the project, and hence will require data derivation procedures to estimate physiological averages from patient phenotypes. Such missing data items could also be used to inform data providers to expose such relevant data items as part of the data collection procedures within future projects. As part of this document, we have attempted to create an initial first draft of a VPHOP Patient Avatar that collects all the necessary clinical data into a unified format. See Annex 8. We have used the openEHR standard described earlier as a vehicle to create a unified record of all the clinical information most likely relevant to the workflow as inputs, or associated outputs to help aid in diagnostic, simulation or post-processing activities. This is, by no means intended to be a final description of a VPHOP Patient Avatar, and we expect the Avatar to evolve as the project progresses.
5.4.5 Legal/Ethical/Security Constraints
Relevant ethical and legal clauses, as part of agreements and consents collected within the VPHOP project will used to create data sharing agreements between the VPHOP project and VPH-Share. The VPHOP project will ensure that all data sharing activities will conform to the data sharing agreements and protocols developed specifically for VPHOP VPH-Share data exposure. As per the description of work, the VPHOP project plans to expose relevant anonymised datasets within the VPH-Share consortium by Year 2, selected and extended release to the VPH community by Year 3 and public release by Year 4, subject to confirmation that the patient information sheets and consent forms support this process. Any necessary further communication with the relevant Research Ethics Committees (RECs) will take place in coming months.
Although not directly concerned with the ethical process, VPH-Share is strongly concerned with the governance process.
Page 74 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
6 DISCUSSION & OUTSTANDING CHALLENGES
A collaborative and domain-expert-led approach to creating consolidated clinical and research information, such as the one presented in this document, is likely to provide numerous benefits:
Shared clinical content combined with specialised domain-expert knowledge that is ratified and vetted through an evolutionary process is bound to produce improved data quality to all the stakeholders. Commonly agreed specifications for data storage and transmission will improve data liquidity and accessibility to allow the data to be used and reused in multiple contexts and modalities. Improve transparency of data held within multiple healthcare silos for the clinicians and patients. Use and re-use of existing concepts and archetypes will increase efficiency and help accelerate the transition process. Provides detailed and standardised provenance, governance and compliance to all the stakeholders. Allows clinicians get back to treating patients, researchers to undertake breakthrough research and software developers to develop applications around a common specification. Common specifications ratified by clinical and domain-experts ensures that the data is safe and ‘fit-for-purpose’
Undoubtedly such integration and knowledge sharing will significantly improve use of gathered data, but many organisations in global health exist to address a single disease or work in a specific sector. There is a real need for mechanisms allowing research organisations, governments, and universities to collaborate outside their usual remit and locations, to maximise the impact of data and available resources, to inform the Patient Avatar and workflows.
To achieve such benefits, VPH-Share should:
Avoid increasing barriers to entry for both clinicians and users Avoid the creation of an inward looking tool Avoid the creation of an isolated silo of healthcare information; yet another “tower of babel of healthcare information”
We believe the Patient Avatar is a strategy that allows sparse, disperse and inconsistent data to be integrated and shared across the VPH via secured access services. It allows users to use a shared global reference scheme to tailor their applications around and hence helps to interoperate with other applications and data.
Page 75 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
7 CONCLUSIONS
The primary issues tackled by this document are: To present in detail the unified representation that VPH-Share will use for clinical data (the core of the patient avatar) and the conceptual process for the linking of these data to the concepts used by the workflows. To analyse the relationship between the concept of a Patient Avatar and Electronic Health Records and, further, to recommend standards for interoperability. To describe in detail the operations performed in each of the four flagship workflows, and particularly to describe the inputs to and outputs from each of these operations. To identify the clinically relevant concepts in the patient avatar for each workflow. To define an initial draft of a patient avatar for each workflow.
The report also serves as the basis for the first exchange of detailed information between the VPH-Share workflows and the technical work packages, WP2, WP3, WP4 and WP6 on the concepts that underpin the VPH patient avatar, as well as for consideration by the Clinical and Ethics Board (CEB) in their production of guidelines for legitimate exposure of these data.
The next steps will be the actual implementation of the avatars for the specific workflows, their consolidation into a single avatar, the confirmation by the workflow leaders of the ethical and governance positions for each of the data items (or combinations, illuminated by the guidelines from the CEB), the mapping of the concepts in the avatar to the inputs and outputs of the workflows, and the first operation of the flagship workflows using the avatar as an underpinning source and repository of information.
VPH-Share believes that applied research delivered through technology will enable highly- desirable disruptive innovation in healthcare, and that the processes developed herein will contribute to this goal. Such innovations hold out the promise of lower cost, higher quality care, and improvements in access to healthcare for many.
Page 76 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
8 REFERENCES
1. Consortium S. Seeding the EuroPhysiome: A Roadmap to the Virtual Physiological Human. .
[Internet]. 2007. Available from: http://www.europhysiome.org/roadmap.
2. Miller K. The Physiome: A Mission Imperative. Biomedical Computation Review. 2010;6(3):8-15.
3. Villa-Uriol MC, Berti G, Hose DR, Marzo A, Chiarini A, Penrose J, et al. @neurIST complex information processing toolchain for the integrated management of cerebral aneurysms. Interface Focus. 2011;1:308-19.
4. Margotta R. The story of medicine. New York,: Golden Press; 1968. 319 p. p.
5. Eichelberg M, Aden T, Riesmeier J, Dogac A, Laleci GB. A survey and analysis of Electronic Healthcare Record standards. Acm Comput Surv. 2005;37(4):277-315.
6. Kalra D. Electronic health record standards. Method Inform Med. 2006;45:136-44.
7. P. S, editor. Requirements for an Electronic Health Record Architecture: International Standards Organisation; 2002.
8. X.A.A.M.Verbeek, Lord WP. The care cycle: an overview. MEDICAMUNDI 2007;51(1).
9. EH. S. The evolution of health-care records in the era of the Internet. Medinfo. 1998;9(1):8-14.
10. Kalra D. The Good European Health Record. Computer methods and programs in biomedicine. 1994;45(1-2):83-9. Epub 1994/10/01.
11. VPH-FET. VPH-FET Research Roadmap Advanced Technologies for the Future of the Virtual Physiological Human 2011. Available from: https://http://www.biomedtown.org/biomed_town/VPHFET/reception/vphfetpublicrep/VPH- FET_final_roadmap.pdf?action=download.
12. openEHR. The openEHR Foundation. 2011 [cited 2011]; Available from: http://www.openehr.org.
13. Ceusters W. Ontology and the future of Evidence-Based Medicine2006.
14. Walker J, Pan E, Johnston D, Adler-Mllstein J, Bates DW, Middleton B. Market watch - The value of health care information exchange and interoperability. Health Affair. 2005;24(2):W510-W8.
Page 77 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
15. Radaelli AG, Hose DR, Hofmann-Apitius M, Friedrich C, Pastor M, Sturkenboom M, et al. D21 - The Virtual Patient Metaphor. @neurIST deliverables. 2008.
16. Munroe R. Standards. In: http://imgs.xkcd.com/comics/standards.png, editor.: XKCD; 2011.
17. Schloeffel P, Beale T, Hayworth G, Heard S, Leslie H. The relationship between CEN 13606, HL7, and openEHR. HIC 2006 Bridging the Digital Divide: Clinician, consumer and computer. 2003.
18. Leslie H. What on earth is openEHR? Archetypical2010.
19. Bowker TJ, Watton PN, Summers PE, Byrne JV, Ventikos Y. Rest versus exercise hemodynamics for middle cerebral artery aneurysms: a computational study. Ajnr American Journal Of Neuroradiology. 2010;31:317-23.
20. Geers AJ, Larrabide I, Radaelli AG, Bogunovic H, Kim M, Gratama Van Andel HAF, et al. Patient-specific computational hemodynamics of intracranial aneurysms from 3D rotational angiography and CT angiography: an in vivo reproducibility study. Ajnr American Journal Of Neuroradiology. 2011;32:581-6.
21. Marzo A, Singh P, Larrabide I, Radaelli A, Coley S, Gwilliam M, et al. Computational hemodynamics in cerebral aneurysms: the effects of modeled versus measured boundary conditions. Annals of Biomedical Engineering. 2011;39:884-96.
22. Singh PK, Marzo A, Howard B, Rufenacht DA, Bijlenga P, Frangi AF, et al. Effects of smoking and hypertension on wall shear stress and oscillatory shear index at the site of intracranial aneurysm formation. Clinical Neurology and Neurosurgery. 2010;112:306-13.
23. Singh PK, Marzo A, Coley SC, Berti G, Bijlenga P, Lawford PV, et al. The Role of Computational Fluid Dynamics in the Management of Unruptured Intracranial Aneurysms: A Clinicians' View. Computational intelligence and neuroscience. 2009;2009:760364.
24. Marzo A, Singh P, Reymond P, Stergiopulos N, Patel U, Hose R. Influence of inlet boundary conditions on the local haemodynamics of intracranial aneurysms. Computer Methods in Biomechanics and Biomedical Engineering. 2009;12:431-44.
25. Valencia C, Villa-Uriol MC, Pozo JM, Frangi AF. Morphological descriptors as rupture indicators in middle cerebral artery aneurysms. Conference Proceedings of the International Conference of IEEE Engineering in Medicine and Biology Society. 2010;2010:6046-9.
26. Zhang C, Villa-Uriol M-C, De Craene M, Pozo JM, Frangi AF. Morphodynamic analysis of cerebral aneurysm pulsation from time-resolved rotational angiography. IEEE transactions on medical imaging. 2009;28:1105-16.
Page 78 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
27. Pozo JM, Villa-Uriol M-C, Frangi AF. Efficient 3D geometric and Zernike moments computation from unstructured surface meshes. IEEE transactions on pattern analysis and machine intelligence. 2011;33:471-84.
28. Radaelli AG, Augsburger L, Cebral JR, Ohta M, Rüfenacht DA, Balossino R, et al. Reproducibility of haemodynamical simulations in a subject-specific stented aneurysm model--a report on the Virtual Intracranial Stenting Challenge 2007. Journal of Biomechanics. 2008;41:2069-81.
29. Singh PK, Marzo A, Staicu C, William MG, Wilkinson I, Lawford PV, et al. The Effects of Aortic Coarctation on Cerebral Hemodynamics and its Importance in the Etiopathogenesis of Intracranial Aneurysms. Journal of Vascular and Interventional Neurology. 2010;3:17-30.
30. Hernandez M, Frangi AF. Non-parametric geodesic active regions: method and evaluation for cerebral aneurysms segmentation in 3DRA and CTA. Medical Image Analysis. 2007;11:224-41.
31. Larrabide I, Kim M, Augsburger L, Villa-Uriol MC, Rüfenacht D, Frangi AF. Fast virtual deployment of self-expandable stents: Method and in vitro evaluation for intracranial aneurysmal stenting. Medical Image Analysis. 2010.
32. Balocco S, Camara O, Vivas E, Sola T, Guimaraens L, Gratama Van Andel HAF, et al. Feasibility of estimating regional mechanical properties of cerebral aneurysms in vivo. Medical Physics. 2010;37:1689-706.
33. Bogunović H, Pozo JMa, Villa-Uriol MaC, Majoie CBLM, van den Berg R, Gratama van Andel HAF, et al. Automated segmentation of cerebral vasculature with aneurysms in 3DRA and TOF-MRA using geodesic active regions: An evaluation study. Medical Physics. 2011;38:210.
34. Zhang C, Villa-Uriol M-C, De Craene M, Pozo JM, Macho JM, Frangi AF. Dynamic estimation of three-dimensional cerebrovascular deformation from rotational angiography. Medical physics. 2011;38:1294-306.
35. Oubel E, Cebral JR, De Craene M, Blanc R, Blasco J, Macho J, et al. Wall motion estimation in intracranial aneurysms. Physiological Measurement. 2010;31:1119-35.
36. Millán RD, Dempere-Marco L, Pozo JM, Cebral JR, Frangi AF. Morphological characterization of intracranial aneurysms using 3-D moment invariants. IEEE transactions on medical imaging. 2007;26:1270-82.
37. Bock J, Frydrychowicz A, Lorenz R, Hirtler D, Barker AJ, Johnson KM, et al. In Vivo Noninvasive 4D Pressure Difference Mapping in the Human Aorta: Phantom Comparison and Application in Healthy Volunteers and Patients. Magn Reson Med. 2011;66(4):1079-88.
Page 79 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
38. Bock J, Frydrychowicz A, Stalder AF, Bley TA, Burkhardt H, Hennig J, et al. 4D Phase Contrast MRI at 3 T: Effect of Standard and Blood-Pool Contrast Agents on SNR, PC- MRA, and Blood Flow Visualization. Magn Reson Med. 2010;63(2):330-8.
39. Krittian S, Lamata P, Bock J, Michlery C, Nordsetten D, Bradley C, et al. A finite- element approach to the direct computation of relative cardiovascular pressure from time- resolved MR velocity data. Medical Image Analysis. in review. 2011.
40. Shortliffe EH, Pagan LM. Expert Systems Research: Modeling the Medical Decision Making Process. Stanford University, 1982.
41. Betts BJ, Shafer RW. Algorithm specification interface for human immunodefiency virus type 1 genotypic interpretation. journal of clinical microbiology. 2003;41(6):2792.
42. Shafer RW. Rationale and uses of a public HIV drug-resistance database. The Journal of infectious diseases. 2006;194 Suppl 1:S51-8. Epub 2006/08/22.
Page 80 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
LIST OF KEY WORDS/ABBREVIATIONS
ADL Archetype Definition Language
CDA Clinical Document Architecture
EHRs Electronic Health Records
HL7 Health Level Seven
IHE Integrating the Health Environment
ISO International Standards Organisation
JSON JavaScript Object Notation
MAF Multimod Application Framework
RIM Reference Information Model
VPH Virtual Physiological Human
YAML Yet Another Mark-up Language
Page 81 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
This page is intentionally blank
Page 82 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
ANNEX 1: @NEURIST WORKFLOW SERVICES
Input Service Output DicomToVTK converter Gimias: Dicom (Dicom Plugin) DICOM Description: generates a vtk image from a dicom image. vtkStructuredPoints No manual interaction required. Volume Rendering vtkStructuredPoints, Gimias: Volume Rendering (Visual Properties menu) visualisation Description: controls visualisation properties (transfer vtkStructuredPoints parameters function values). Manual interaction required. ROI vtkStructuredPoints, Gimias: Select ROI vtkStructuredPoints ROI Description: volume selector Manual interaction required. GAR segmentation VTK, imaging Gimias: GARWidget modality, ROI, config VTK PolyData Description: creates a vessels and aneurysm vtk model. parameters No manual interaction required. MESH Editing Gimias: VTK PolyData Description: cleaning of vessels and aneurysm vtk VTK PolyData image. Manual interaction required. Skeletonisation Gimias: skeletonisation VTK PolyData Description: necessary to perform perpendicular cuts and VTK PolyData the setting of hemodynamic boundary conditions. Manual interaction required. Neck Selection Gimias: Manual Neck Cutting VTK PolyData VTK PolyData Description: it is used to isolate the dome. Manual interaction required. Aneurysm isolation Gimias: Description: cuts vessels on aneurysm region (used for VTK PolyData VTK PolyData Zernike moments calculation & count of attached vessels). Manual interaction required. Morphological Descriptors Gimias: Aneurysm Descriptors VTK PolyData Description: calculates aneurysm depth, width, surface, APD (.XML, .vtk) volume… & Zernike moments No manual interaction required. Applying Boundary Conditions Gimias: no (aneufuse) VTK PolyData, 1D Description: sets boundary conditions for hemodynamics model APD (.XML, .vtk) calculation using a 1D model. It uses the skeleton of the
vascular model as a reference. Manual interaction required.
Page 83 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Hemodynamic simulation pre-processor Gimias: no (aneufuse, currently the output is specific for ANSYS ICEM and CFX tools) APD(.XML, .vtk) .cgns, .ccl Description: creates the configuration files required by the selected solver to perform a hemodynamic simulation No manual interaction required. Volumetric Meshing Gimias: no (call to a commercial software from ANSYS: .cgns ICEM) .msh Description: creates a volumetric mesh starting from a surface mesh Flow Simulation Gimias: no (call to a commercial software from ANSYS: (.ccl, .msh) (.res) CFX) Description: solves flow equations Flow simulation post-processing Gimias: no (performed within ANSYS) (.res, .cse) Description: starting from the flow simulation result, it .csv computes the hemodynamic descriptors specified in the .cse file
Page 84 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
ANNEX 2: @NEURIST WORKFLOW SCHEMATIC DIAGRAM
map
stress
descriptors computes
shear
.csv
wall
ccl
INTERACTION
Simulation Flow
Input: Output: Description: hemodynamic
flow stress (ICEM) (CFX)
mesh,
shear solves
GIMIAS @NEUFUSE ANSYS ANSYS MANUAL REQUIRED
wall
volumetric
a Flow
the
mesh
Input: Output: map Description: of mesh Definitions:
creates
mesh volumetric
surface
Volumetric ccl
Input: Output: Description: volumetric
mesh
mesh,
model
Defines
surface depth…
surface
xml,
mesh
1Dmodel vtk
surface,
HD Input: Output: Description: hemodynamic calculation
xml,
hemodynamic mesh, surface
vtk boundary
ZMI
for Descriptors Morphology xml,
Input: Output: Description: and surface
Input: Output: Description: conditions Selecting Boundary
neck cut
selection vessel mesh mesh set
a mesh mesh
to aneurysm
aneurysm dome
tion using surface surface and
surface surface
mesh.
conditions
necessary Aneurysm isola Neck
Input: Output: Description: surface Input: Output: Description: isolation skeleton.
surface
boundary
Skeletonizati Input: Output: Description: the
g
mesh vessels
closing
mesh.
and
mesh.
surface Editin clipping
thi )
cells
and surface
surface
mesh.
cleaning
Mesh vessels and Input: Output: Description: (removing hl
Image,Bounding
surface
3D
GAR Segmentation Input: Output: Description: Box
Box
volume and
image
Bounding
3D
ROI aneurysm
image. Input: Output: Description:
image.
3D
visualization 3D
Rendering Volume dicom
Input: Output: Description: vessels a
image
Converts
image
VTK 3D
to dicom
Dicom Input: Output: Description: image Page 85 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
ANNEX 3: VIROLAB LISTINGS
{ "rank": [ { "system":"ANRS", "version":"2008.07", "region":"reverse_transcriptase", "mutations": ["44D"], "rankings": { "NVP": ["1", "Susceptible", "S"], "EFV": ["1", "Susceptible", "S"], "ETV": ["1", "Susceptible", "S"] } }, { "system":"Rega", "version":"8.0.1", "region":"reverse_transcriptase", "mutations": ["44D"], "rankings": { "AZT": ["1", "Susceptible GSS 1", "S"], "DDI": ["1", "Susceptible GSS 1", "S"], "D4T": ["1", "Susceptible GSS 1", "S"], "3TC": ["1", "Susceptible GSS 1", "S"], "ABC": ["1", "Susceptible GSS 1", "S"], "FTC": ["1", "Susceptible GSS 1", "S"], "TDF": ["1", "Susceptible GSS 1", "S"] } }, { "system":"Rega", "version":"8.0.1", "region":"reverse_transcriptase", "mutations": ["44D"], "rankings": { "NVP": ["1", "Susceptible GSS 1", "S"], "DLV": ["1", "Susceptible GSS 1", "S"], "EFV": ["1", "Susceptible GSS 1", "S"], "ETV": ["1", "Susceptible GSS 1", "S"] } } ] } Listing 1: Sample Output of the Comparative Drug Ranker
Page 86 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Page 87 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
{ "literature": [ { "publication_id": "12654666", "query": "54V,82A,84V,90M,SQV", "sentences": [ { "drugs": [ "atazanavir" ], "mutations": [ "10I/V/F", "20R/M/I", "24I", "33I/F/V", "36I/L/V", "46I/L", "48V", "54V/L", "63P", "71V/T/I", "73C/S/T/A", "82A/F/S/T", "84V", "90M" ], "relations": [ "10I/V/F decreased susceptibility to ATV", "20R/M/I decreased susceptibility to ATV", "24I decreased susceptibility to ATV", "33I/F/V decreased susceptibility to ATV", "36I/L/V decreased susceptibility to ATV", "46I/L decreased susceptibility to ATV", "48V decreased susceptibility to ATV", "54V/L decreased susceptibility to ATV", "63P decreased susceptibility to ATV", "71V/T/I decreased susceptibility to ATV", "73C/S/T/A decreased susceptibility to ATV", "82A/F/S/T decreased susceptibility to ATV", "84V decreased susceptibility to ATV", "90M decreased susceptibility to ATV" ], "sentence": "Analysis of the genotypic profiles of 943 PI-susceptible and -resistant clinical isolates identified a strong correlation between the presence of amino acid changes at specific residues (10I/V/F, 20R/M/I, 24I, 33I/F/V, 36I/L/V, 46I/L, 48V, 54V/L, 63P, 71V/T/I, 73C/S/T/A, 82A/F/S/T, 84V, and 90M) and decreased susceptibility to atazanavir" } ] } } Listing 3: Partial Sample Output from Literature Miner
Page 88 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
ANNEX 4: @NEURIST COMMON REFERENCE INFORMATION MODEL
Page 89 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
ANNEX 5: @NEURIST PATIENT AVATAR I. Patient Demographic Data
ID eu.vph‐[email protected]_details.v1 Description Demographic data about a person such as birth data, sex, height, weight and ethnic group Keywords demographic service, person identifier, person's demographic data Occurrences 1…1 (mandatory) Cardinality 1…1 (mandatory) References openEHR‐DEMOGRAPHIC‐ITEM_TREE.person_details.v1
Patient ID The combination of identifier type, identifier issuer and identifier name that specify the link between this name and reporting or other unique identifier usage. Occurrences: 1…1 (mandatory) Identifier Birth Date The date of birth of a person Occurrences: 1…1 (mandatory) Date Sex The sex of the person Occurrences: 1…1 (mandatory) Coded Text: Male Female Intersex/Indeterminate Height The height of the person Occurrences: 1…1 (mandatory) Quantity (Units: cm) Weight The weight of the person Occurrences: 1…1 (mandatory) Quantity (Units: kg) Ethnic The person’s ethnic background Background Occurrences: 0…* (optional) Free or Coded Text
II. Personal and Social history
ID eu.vph‐[email protected]_and_social_history.v1 Description Record the personal and social circumstances of the person Keywords Person, social history, ethnicity, marital status, Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.personal_and_social_history.v4
Maternal Ethnic background of mother Ethnicity Occurrences: 0…1 (optional)
Page 90 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Coded Text: White ‐ British White ‐ Irish White ‐ other Mixed ‐ white and black Caribbean Mixed ‐ white and black African Mixed ‐ white and Asian Mixed ‐ other Asian/Asian British ‐ Indian Asian/Asian British ‐ Pakistani Asian/Asian British ‐ Bangladeshi Asian/Asian British ‐ other Asian Chinese Paternal Ethnic background of father Ethnicity Occurrences: 0…1 (optional) Coded Text: White ‐ British White ‐ Irish White ‐ other Mixed ‐ white and black Caribbean Mixed ‐ white and black African Mixed ‐ white and Asian Mixed ‐ other Asian/Asian British ‐ Indian Asian/Asian British ‐ Pakistani Asian/Asian British ‐ Bangladeshi Asian/Asian British ‐ other Asian Chinese Marital Status Marital Status Occurrences: 0…1 (optional) Coded Text: Widowed Divorced Separated Married (incl. civil partnership and common‐law) Partner Single ‐ supported Single ‐ unsupported Household Description of others with whom the subject resides Composition Occurrences: 0…1 (optional) Coded Text: Sole parent with dependant(s) only Couple only Couple with dependant(s) only Family (with non‐related member(s) present) Family (with other family member(s) present) Group (unrelated adults)
Page 91 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Single (person living alone) Type of The setting in which the person lives Accommodati Occurrences: 0…1 (optional) on Coded Text Private residence, including privately and publicly rented homes Psychiatric hospital Specialised alcohol/other drug treatment residence Specialised mental health community‐based residential support service Domestic‐scale supported living facility Boarding/rooming house/hostel or hostel type accommodation, not including aged persons' hostel Homeless persons' shelter Shelter/refuge (not including homeless persons' shelter) Other supported accommodation Prison/remand centre/youth training centre Public place (homeless)
III. Fitness and Lifestyle
ID eu.vph‐[email protected] Description A short object to capture basic details about a person's lifestyle, diet, etc. Keywords person, activity, fitness, diet Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.lifestyle.v3
Activity Level Occurrences: 0…1 (optional) Coded Text: Active Semi‐Active Sedentary Fitness Level Occurrences: 0…1 (optional) Coded Text: Fit Unfit Type of Occurrences: 0…1 (optional) Exercise Free or Coded Text Frequency Occurrences: 0…1 (optional) Quantity (Units: Number) /d /yr /wk Average Occurrences: 0…1 (optional) Duration Quantity (Units: Number) hours, months Diet Occurrences: 0…1 (optional)
Page 92 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Coded Text: Normal Vegetarian Vegan Lactose free Gluten free Special Diet Details Occurrences: 0…1 (optional) Free or Coded Text
IV. Employment Details
ID eu.vph‐[email protected]_details.v1 Description To record the current and past employment details of a person Keywords substance, addiction, consumption, use, alcohol Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐CLUSTER.employment_details.v5
Current Identification of substance employment Occurrences: 1…1 (mandatory) status Cardinality: 0…1 (optional) Coded Text: Employed Employed part time Unemployed Retired Volunteer Carer Student Sick or disabled permanently Sick or disabled temporarily Current Current Occupation of the person Occupation Occurrences: 0…1 (optional) Cardinality: 0…1 (optional, non‐repeating) Free or Coded Text Date of Date of Employment Employment Occurrences: 0…1 (optional) Date/Time Role/Job Role/Job Title Occurrences: 0…* (optional, repeating) Free or Coded Text Occupation Occupation Occurrences: 0…1 (optional) Free or Coded text Occupational Overview of occupational health and safety risk Health & Occurrences: 0…1 (optional)
Page 93 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Safety Risk Cardinality: 0…* (optional, repeating, unordered) Identified Risks identified Risk Occurrences: 0…1 (optional) Free or Coded Text Exposure Details of exposure Details Occurrences: 0…1 (optional) Free or Coded Text
V. Vital Signs A. Heart Rate
ID eu.vph‐[email protected]_rate.v1 Description The rate the heart is beating ‐ either mechanically or electrically Keywords heart rate, vital signs Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.heart_rate.v3
Rate The rate of the heart as beats per minute Occurrences: 0…1 (optional) Quantity (Units: Number) /min limit decimal places = 0 Rhythm The rhythm of the heart beat Occurrences: 0…1 (optional) Coded Text: Regular Irregular Irregularly irregular Description The description of the rate and rhythm Occurrences: 0…1 (optional) Free or Coded Text Position The position of the patient when the heart rate was measured Occurrences: 0…1 (optional) Coded Text: Lying Sitting Reclining Standing Device Device by which the heart rate was measured Occurrences: 0…1 (optional) Free Text
B. Blood Pressure
ID eu.vph‐[email protected]_pressure.v1 Description The measurement by any means (invasive or non‐invasive) of systemic
Page 94 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
arterial blood pressure which is deemed to represent the actual systemic blood pressure Keywords Blood, blood pressure, vital signs Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.blood_pressure.v5
Systolic Peak systemic arterial blood pressure over one cycle ‐ measured in systolic or contraction phase of the heart cycle [SNOMED‐CT: 163030003] Occurrences: 1…1 (mandatory) Quantity (Units: mm[Hg]) 0…<1000 Diastolic Minimum systemic arterial blood pressure over one cycle ‐ measured in the diastolic or relaxation phase [SNOMED‐CT: 163031004] Occurrences: 1…1 (mandatory) Quantity (Units: mm[Hg]) 0…<1000 Mean Arterial The average arterial pressure that occurs over the entire Pressure course of the heart contraction and relaxation cycle ‐ calculated by (2XSBP + DBP) divided by 3. Occurrences: 0…1 (optional) Quantity (Units: mm[Hg]) 0…<750 Limit decimal places = 1 Pulse Pressure The variation in pressure over one contraction cycle Occurrences: 0…1 (optional) Quantity (Units: mm[Hg]) 0…<750 Limit decimal places = 1 Ankle Brachial A measure of the reduction in arterial blood pressure of the Pressure legs used to detect evidence of blockages (peripheral Index vascular disease). It is calculated by dividing the highest systolic blood pressure in the arteries at the ankle and foot by the higher of the two systolic blood pressures in the arms. Occurrences: 0…1 (optional) Quantity (Units: Number) >=0 limit decimal places = 1 State The position and exertion level at which the reading was taken. Occurrences: 0…1 (optional) Cardinality: 0…1 (optional) Position The position of the patient at the time of measuring blood pressure Occurrences: 1…1 (mandatory) Coded Text: Standing Sitting Reclining Lying Exertion The level of exertion at the time of taking Level the measurement
Page 95 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Occurrences: 0…1 (optional) Quantity (Unit: J/min) 0…1000 Exercise The classification of the exercise level Occurrences: 0…1 (optional) Coded Text: At rest Post‐exercise During exercise Tilt The tilt of the surface on which the person is lying Occurrences: 0…1 (optional) Quantity (Unit: Angle) ‐90…90 History Historical readings taken at 5 and 10 minute intervals Occurrences: 0…1 (optional) Cardinality: 0…1 (optional) Baseline Baseline event in event history Occurrences: 0…1 (optional) PointInTime 5 minute Blood pressure reading after 5 minutes rest reading Occurrences: 0…1 (optional) PointInTime 10 minute Blood pressure reading after 10 minutes reading rest Occurrences: 0…1 (optional) PointInTime Postural The difference between standing and Change sitting/lying blood pressure Occurrences: 0…* (optional) PointInTime Paradox Variation in blood pressure with respiration Occurrences: 0…* (optional) PointInTime Cuff Size The size of the cuff if a sphygmomanometer is used [SNOMED‐CT: 246153002] Occurrences: 0…1 (optional) Coded Text: Adult Large Adult Paediatric/Child Adult Thigh Neonatal Infant Small Adult Instrument The instrument used to measure the blood pressure [SNOMED‐CT: 57134006] Occurrences: 0…1 (optional) Free or Coded Text
Page 96 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Location of The site of the measurement of the blood pressure measurement Occurrences: 0…1 (optional) Coded Text: Right arm Left arm Right leg Left leg Intra‐arterial Right wrist Left wrist Korotkoff Record which Korotkoff sound is used for determining sounds Diastolic pressure Coded Text: Fourth sound Fifth sound Comment Comment on blood pressure reading Occurrences: 0…1 (optional) Free or Coded Text
C. Respiration
ID eu.vph‐[email protected] Description The rate and character of breathing Keywords Respiration, vital signs Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.respiration.v7
Rate The rate of respirations Occurrences: 1…1 (mandatory) Quantity (Units: Number) /min >=0 Rhythm The rhythm of the respiration Occurrences: 0…1 (optional) Coded Text: Regular Irregular Cheyne‐Stokes Apnoeic episodes Character The character of the respirations Occurrences: 0…1 (optional) Coded Text: Gasping Grunting Kussmaul Snoring Inspiratory stridor Paradoxical breathing
Page 97 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Recessing Nasal flare Apnoea Breathlessness Cough Excessive Secretions Wheeze None Depth Depth of respiration Occurrences: 0…1 (optional) Coded Text: Shallow Normal Deep FiO2 Fraction of inspired oxygen Occurrences: 0…1 (optional) Quantity (Unit: Percentage) % 0…100 Comments Any comments about the respiration Occurrences: 0…1 (optional) Free Text
D. Body Temperature
ID eu.vph‐[email protected]_temperature.v1 Description An estimate of the core temperature of the body Keywords body temperature, vital signs Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.body_temperature.v5
Temperature The core body temperature Occurrences: 1…1 (mandatory) Quantity (Units: Degree) °C °F Thermal The thermal situation of the person who is having the Situation temperature taken Occurrences: 0…1 (optional) Coded Text: Indoor ‐ normal clothing or bedding Indoor ‐ reduced clothing or bedding Indoor ‐ increased clothing or bedding Outdoors ‐ normal clothing Outdoors ‐ reduced clothing Outdoors ‐ increased clothing Thermal stress ‐ downward Thermal stress ‐ upward Paediatric incubator Naked
Page 98 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Ambient The temperature to which the person has been exposed Temperature Occurrences: 0…1 (optional) Quantity (Units: Degree) °C °F Description of Description of the conditions applied to the patient to Thermal change temperature Stress Occurrences: 0…1 (optional) Free or Coded Text Site of The site of measurement of the temperature Measurement Occurrences: 0…1 (optional) Coded Text: Oral Aural Axilla Rectal Core Urinary bladder Intravascular Temporal
VI. Substance Use A. Alcohol
ID eu.vph‐[email protected]_use_summary‐alcohol.v1 Description Archetype to record a persisting summary or overview of use or consumption of alcohol at the present time, a specific time or over a period of time. Keywords substance, addiction, consumption, use, alcohol Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐EVALUATION.substance‐alcohol.v1
Substance Identification of substance Occurrences: 1…1 (mandatory) Coded Text: Alcohol Usage Status Overview of usage of alcohol Occurrences: 1…1 (mandatory) Coded Text: Current User Former Regular User Former Occasional User Never Used Form Form of the alcohol used Occurrences: 0…1 (optional) Coded Text: All alcohol All beer All wine
Page 99 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
All spirits Full strength beer Light beer Red wine White wine Fortified wine Date Date when use commenced Commenced Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??) Date ceased Date when used ceased Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??) Standard Frequency of standard drinks of alcohol consumed Drinks Occurrences: 1…1 (mandatory) Quantity (Units: Unit) unit/h unit/d unit/wk Comment Other information of substance use Occurrences: 0…1 (optional) Free or Coded Text B. Tobacco
ID eu.vph‐[email protected]_use_summary‐tobacco.v1 Description Archetype to record a persisting summary or overview of use or consumption of tobacco at the present time, a specific time or over a period of time. Keywords substance, addiction, consumption, use, tobacco Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐EVALUATION.substance‐tobacco.v1
Substance Identification of substance Occurrences: 1…1 (mandatory) Coded Text: Tobacco Usage Status Overview of usage of tobacco Occurrences: 1…1 (mandatory) Coded Text: Current User Former Regular User Former Occasional User Never Used Form Form of the tobacco used Occurrences: 0…1 (optional) Coded Text: Cigarettes ‐ manufactured Cigarettes ‐ roll‐your‐own
Page 100 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Cigars Pipe Date Date when use commenced Commenced Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??) Date ceased Date when used ceased Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??) Number Frequency of units containing tobacco consumed e.g. Smoked cigarettes or cigars Occurrences: 1…1 (mandatory) Quantity (Units: Unit) unit/h unit/d unit/wk Comment Other information of substance use Occurrences: 0…1 (optional) Free or Coded Text
C. Caffeine
ID eu.vph‐[email protected]_use_summary‐caffeine.v1 Description Archetype to record a persisting summary or overview of use or consumption of caffeine at the present time, a specific time or over a period of time. Keywords substance, addiction, consumption, use, caffeine Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐EVALUATION.substance‐caffeine.v1
Substance Identification of substance Occurrences: 1…1 (mandatory) Coded Text: Caffeine Usage Status Overview of usage of caffeine Occurrences: 1…1 (mandatory) Coded Text: Current User Former Regular User Former Occasional User Never Used Form Form of the caffeine used Occurrences: 0…1 (optional) Coded Text: Coffee ‐ instant Coffee ‐ brewed/filtered Coffee ‐ espresso Tea
Page 101 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Soft drink Date Date when use commenced Commenced Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??) Date ceased Date when used ceased Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??) Amount Frequency consumed ‐ only one quantity is permitted Consumed Occurrences: 0…1 (optional) Cardinality: 0…1 (optional) Cups of Consumption of coffee or tea coffee or tea Occurrences: 0…* (optional, repeating) Quantity (Units: Cups) cups/d cups/wk Shots of Consumption of espresso coffee by shots espresso Occurrences: 0…1 (optional) coffee Quantity (Units: Number) >=0 Volume of Consumption of caffeine‐containing soft soft drink drink by volume Occurrences: 0..* (optional, repeating) Quantity (Units: Millilitre) ml/d ml/wk Comment Other information of substance use Occurrences: 0…1 (optional) Free or Coded Text
VII. Aneurysm Related Health Event
ID eu.vph‐[email protected]_health_event.v1 Description A recording about an endovascular procedure related event. Keywords Aneurysm, health event Occurrences 0…1 (optional) Cardinality 0…* (optional, repeating, unordered) References openEHR‐EHR‐CLUSTER.health_event.v1
Event Type Type of event that has occurred Occurrences: 1…1 (mandatory) Choice: Endovascular Procedure Cerebrovascular Surgery Event Details A clinical description of what happened. Occurrences: 0…1 (optional) Free or Coded Text Occurrence The time between the event and the observation time.
Page 102 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Occurrences: 0…1 (optional) Duration Preceding Symptoms and events which preceded the index event. symptoms Occurrences: 0…1 (optional) and events Include: openEHR‐EHR‐CLUSTER.symptom.v1 Associated Symptoms and events which associated the index event. symptoms Occurrences: 0…1 (optional) and events Include: openEHR‐EHR‐CLUSTER.symptom.v1 Date The date and time that procedure was performed. Performed Occurrences: 0…1 (optional) Date/Time
VIII. Supporting Risk Factors
ID eu.vph‐[email protected]_risk_factors.v1 Description A diagnosis defined by a clinician which is coded in an accepted terminology and may include the stage of the condition and the diagnostic criteria. Keywords Aneurysm, risk factors Occurrences 0…1 (optional) Cardinality 0…* (optional, repeating, unordered) References openEHR‐EHR‐EVALUATION.problem‐diagnosis.v1
Diagnosis The index Diagnosis Occurrences: 1…1 (mandatory) Free Text or Choice: Abdominal aneurysm Autosominal dominant policytic kidney disease Atherosclerosis Moya‐Moya Arterio‐Venous Malformation Ehlers‐Danlos Syndrome Coarctation of aorta Hypercoagulation state Multiple intracranial aneurysms Hypertension Previous subarachnoid haemhorrage a1‐antitrypsin deficiency fibromuscular dysplasia Heart valve disease Brain tumor Marfan syndrome Past menigitis Neurofibromatosis type 1 Pseudoxanthoma Elasticum Recent severe brain injury Rendu‐Osler Weber disease Tuberous sclerosis
Page 103 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Sickle Cell disease Former vasculaitis State The status of the diagnosis Occurrences: 1…1 (mandatory) Coded Text: Confirmed Provisional Working Clinical Description of the clinical aspects of the problem Description Occurrences: 0…1 (optional) Free or Coded Text Severity The severity index of the problem Occurrences: 0…1 (optional) Ordinal 1. Mild 4. Moderate 7. Severe Date of last The date of last occurrence or exacerbation occurrence Occurrences: 0…1 (optional) Date/Time Family History Risk of condition based on family history Occurrences: 0…1 (optional) Include: openEHR‐EHR‐EVALUATION.risk‐family_history.v1
IX. Specimen
ID eu.vph‐[email protected] Description To record details of a laboratory specimen. Will often be used in different contexts e.g within an Instruction archetype to describe the specimen that has to be taken, or describing the specimen which accompanies the laboratory request. It may occur within an Action archetype e.g. describing specimens taken as part of a surgical procedure. Keywords specimen Occurrences 1…1 (mandatory) Cardinality 1…* (mandatory, repeating, unordered) References openEHR‐EHR‐CLUSTER.specimen.v1
Specimen Unique identifier of the specimen, normally assigned by the Identifier laboratory. Occurrences: 1…1 (mandatory) Identifier Specimen The type of specimen to be collected e.g. venous blood, Tissue Type prostatic biopsy. Occurrences: 0…1 (optional) Free or Coded Text Collection The method of collection to be used e.g. Venepuncture,
Page 104 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Procedure biopsy, resection. Occurrences: 0…1 (optional) Free or Coded Text Site The anatomical site(s) from where the specimen was taken. Occurrences: 0…* (optional, repeating) Include: openEHR‐EHR‐CLUSTER.physical_properties.v1 and specialisations Physical Dimensions / weight of sample. Set as unbounded to allow Details variations e.g Weight of prostatic gland with and without seminal vesicles Occurrences: 0…* (optional, repeating) Include: openEHR‐EHR‐CLUSTER.physical_properties.v1 and specialisations Date and Time The date and time that collection has been ordered to take of Collection place or has taken place. Occurrences: 0…1 (optional) Date/Time
X. Medications – Contraceptives, Blood Thinning agents
ID eu.vph‐[email protected] Description For recording questions and answers about medication use. Keywords Heart event, history Occurrences 0…1 (optional) Cardinality 0…* (optional, repeating, unordered) References openEHR‐EHR‐EVALUATION.check_list‐medication.v3
Medication Name of medication used or previously taken Occurrences: 1…1 (mandatory) Free Text or Choice: Medication ID SNOMED‐CT ID of the Medication Prescribed Occurrences: 1…1 (mandatory) Coded Text Type Occurrences: 1…1 (mandatory) Free Text or Choice: Contraceptives Blood Thinning Agents Dose Amount of drug prescribed to be taken daily Occurrences: 1…1 (mandatory) Quantity (Units: mg) /d Date Last Date the medication was last taken Used Occurrences: 0…1 (optional) Date/Time
Page 105 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
XI. Aneurysm Imaging Study
ID eu.vph‐[email protected]_study.v1 Description An action related to an investigation by an imaging technique. Keywords image, Xray, ultrasound, MRI, magnetic resonance, CT, scan, tomography Occurrences 1…1 (mandatory) Cardinality 1…* (mandatory, repeating, unordered) References openEHR‐EHR‐CLUSTER.imaging.v1
Clinical Clinical Findings relevant to the imaging investigations Findings Occurrences: 0…1 (optional) Free or Coded Text Imaging The Type of imaging Category Occurrences: 0…1 (optional) Free or Coded Text: Xray CT scan Perfusion scan Ultrasound Echocardiogram MR Imaging Test Imaging test requested or performed Name Occurrences: 0…1 (optional) Free or Coded Text Study The study identifier the imaging procedure is related to Identifier Occurrences: 0…1 (optional) Identifier Anatomical The anatomical site(s) to be imaged Location Occurrences: 0…* (optional, repeating) Include: openEHR‐EHR‐CLUSTER.physical_properties.v1 and specialisations Aneurysm Specific details of aneurysm detected like type, location, Details status, blebs, lobules, aspects, perforators, size and volume. Occurrences: 1…1 (mandatory) Cardinality: 1…1 (mandatory) Aneurysm ID Unique identifier associated with detected aneurysm Occurrences: 1…1 (mandatory) Identifier Type Type of aneurysm Occurrences: 1…1 (mandatory) Coded Text: Saccular ‐ Side‐Wall Saccular ‐ Bifurcation Fusiform ‐ Dissecting Fusiform ‐ Non Dissecting
Page 106 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Fusiform ‐ Segmental ectasy Fusiform ‐ Transitional Location The anatomical location of detected aneurysm Occurrences: 1…1 (mandatory) Coded Text: Intracavernous internal carotid Ophthalmic segment carotid Medial wall carotid Posterior Comm Ant Choroidal segment carotid Anterior and superior wall carotid Carotid bifurcation A1 segment ant Ant communicating artery A2 segment ant Pericallosal cerebral artery Distal ant cerebral artery M1 segment middle cerebral artery Sylvian bifurcation Distal to sylvian bifurcation V4 segment vertebral artery PICA AICA Superior cerebellar artery Basilar trunk Basilar Tip P1 Posterior cerebral artery P1‐P2 junction posterior cerebral artery P2 posterior cerebral artery Distal posterior cerebral artery Rupture Status of the Rupture Status Occurrences: 1…1 (mandatory) Coded Text Aspect Qualitative or Clinical assessment or aneurysmal wall surface Occurrences: 0…1 (optional) Coded Text: Smooth Rough Blebs Focal outpunchings on aneurysmal wall Occurrences: 0…1 (optional) Coded Text: No One Two Multiple
Page 107 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Lobules Secondary enlargements attached to an aneurysm Occurrences: 0…1 (optional) Coded Text: No One Two Multiple prox (To be defined) Occurrences: 0…1 (optional) Boolean Thrombosis Presence of Thrombosis Occurrences: 0…1 (optional) Boolean Calcification Presence of Calcification Occurrences: 0…1 (optional) Boolean Perforators Vessels that lead from or to the aneurysm Occurrences: 0…1 (optional) Coded Text: No Origin less than 1mm from neck Origin from the dome Adherent to the dome Size/Volume Size and volume measurements of the aneurysm Occurrences: 1…1 (mandatory) Cardinality: 1…1 (mandatory) Collar Size Size of the aneurysm collar Occurrences: 0…1 (optional) Quantity (Unit: mm) Dome Size Size of the aneurysm dome Occurrences: 0…1 (optional) Quantity (Unit: mm) Max Diameter Maximum diameter of the aneurysm Occurrences: 0…1 (optional) Quantity (Unit: mm) Perpendicular Perpendicular Diameter of Diameter 1 the one plane Occurrences: 0…1 (optional)
Page 108 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Quantity (Unit: mm) Perpendicular Perpendicular Diameter of Diameter 2 the secondary plane Occurrences: 0…1 (optional) Quantity (Unit: mm) Volume Estimated Volume of the aneurysm Occurrences: 0…1 (optional) Quantity (Unit: cm3) View Details about a particular view Occurrences: 0…* (optional, repeating) Cardinality: 1…* (mandatory, repeating, unordered) View Name A description of the view taken Occurrences: 0…1 (optional) Free or Coded Text Per View Findings related to the view taken Findings Occurrences: 0…1 (optional) Free Text Image Unique identifier of the image, normally Identifier assigned by the healthcare organisation or device. Occurrences: 1…1 (mandatory) Identifier Image Link to Multimedia Image Occurrences: 1…1 (mandatory) URI Overall Summary of imaging findings Findings Occurrences: 0…1 (optional) Free or Coded Text Imaging Information regarding the quality of the imaging that may Quality influence reporting Occurrences: 0…1 (optional) Free or Coded Text Date of The date of the imaging is to be or was carried out Imaging Occurrences: 0…1 (optional) Date/Time Location Occurrences: 0…1 (optional) Free or Coded Text
XII. Imaging Details
ID eu.vph‐[email protected]_details.v1 Description Details of imaging, used in requests for imaging, records of imaging procedures and imaging reports. Keywords image, mri, x‐ray,
Page 109 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Occurrences 1…1 (mandatory) Cardinality 1…* (mandatory, repeating, unordered) References openEHR‐EHR‐CLUSTER.imaging.v1
Imaging The Type of imaging Category Occurrences: 0…1 (optional) Free or Coded Text Imaging Test Imaging test requested or performed Name Occurrences: 0…1 (optional) Free or Coded Text Study Identifier for the related study Identifier Occurrences: 0…1 (optional) Identifier Anatomical The anatomical site(s) to be imaged Location Occurrences: 0…* (optional, repeating) Include: openEHR‐EHR‐CLUSTER.physical_properties.v1 and specialisations View Details about a particular view Occurrences: 0…* (optional, repeating) Cardinality: 1…* (mandatory, repeating, unordered) View Name A description of the view taken Occurrences: 0…1 (optional) Free or Coded Text Per View Findings related to the view taken Findings Occurrences: 0…1 (optional) Free or Coded Text Image Unique identifier of the image, normally Identifier assigned by the healthcare organisation or device. Occurrences: 1…1 (mandatory) Identifier Image Link to Multimedia Image Occurrences: 1…1 (mandatory) URI Overall Summary of imaging findings Findings Occurrences: 0…1 (optional) Free or Coded Text Imaging Information regarding the quality of the imaging that may Quality influence reporting Occurrences: 0…1 (optional) Free or Coded Text
Page 110 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
ANNEX 6: EUHEART PATIENT AVATAR I. Patient Demographic Data
ID eu.vph‐share.euHeart.person_details.v1 Description Demographic data about a person such as birth data, sex, height, weight and ethnic group Keywords demographic service, person identifier, person's demographic data Occurrences 1…1 (mandatory) Cardinality 1…1 (mandatory) References openEHR‐DEMOGRAPHIC‐ITEM_TREE.person_details.v1
Patient ID The combination of identifier type, identifier issuer and identifier name that specify the link between this name and reporting or other unique identifier usage. Occurrences: 1…1 (mandatory) Identifier Birth Date The date of birth of a person Occurrences: 1…1 (mandatory) Date (yyyy‐mm‐dd) Sex The sex of the person Occurrences: 1…1 (mandatory) Coded Text: Male Female Intersex/Indeterminate Height The height of the person Occurrences: 1…1 (mandatory) Quantity (Units: cm) Weight The weight of the person Occurrences: 1…1 (mandatory) Quantity (Units: kg) Ethnic The person’s ethnic background Background Occurrences: 0…* (optional) Free or Coded Text
II. Personal and Social history
ID eu.vph‐share.euHeart.personal_and_social_history.v1 Description Record the personal and social circumstances of the person Keywords Person, social history, ethnicity, marital status, Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.personal_and_social_history.v4
Maternal Ethnic background of mother Ethnicity Occurrences: 0…1 (optional)
Page 111 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Coded Text: White ‐ British White ‐ Irish White ‐ other Mixed ‐ white and black Caribbean Mixed ‐ white and black African Mixed ‐ white and Asian Mixed ‐ other Asian/Asian British ‐ Indian Asian/Asian British ‐ Pakistani Asian/Asian British ‐ Bangladeshi Asian/Asian British ‐ other Asian Chinese Paternal Ethnic background of father Ethnicity Occurrences: 0…1 (optional) Coded Text: White ‐ British White ‐ Irish White ‐ other Mixed ‐ white and black Caribbean Mixed ‐ white and black African Mixed ‐ white and Asian Mixed ‐ other Asian/Asian British ‐ Indian Asian/Asian British ‐ Pakistani Asian/Asian British ‐ Bangladeshi Asian/Asian British ‐ other Asian Chinese Marital Status Marital Status Occurrences: 0…1 (optional) Coded Text: Widowed Divorced Separated Married (incl. civil partnership and common‐law) Partner Single ‐ supported Single ‐ unsupported Household Description of others with whom the subject resides Composition Occurrences: 0…1 (optional) Coded Text: Sole parent with dependant(s) only Couple only Couple with dependant(s) only Family (with non‐related member(s) present) Family (with other family member(s) present) Group (unrelated adults) Single (person living alone)
Page 112 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
III. Fitness and Lifestyle
ID eu.vph‐share.euHeart.lifestyle.v1 Description A short object to capture basic details about a person's lifestyle, diet, etc. Keywords person, activity, fitness, diet Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.lifestyle.v3
Activity Level Occurrences: 0…1 (optional) Coded Text: Active Semi‐Active Sedentary Fitness Level Occurrences: 0…1 (optional) Coded Text: Fit Unfit Type of Occurrences: 0…1 (optional) Exercise Free or Coded Text Frequency Occurrences: 0…1 (optional) Quantity (Units: Number) /d /yr /wk Average Average duration of activity Duration Occurrences: 0…1 (optional) Quantity (Units: Number) hours, months Diet Occurrences: 0…1 (optional) Coded Text: Normal Vegetarian Vegan Lactose free Gluten free Special Diet Details Occurrences: 0…1 (optional) Free or Coded Text
IV. Employment Details
ID eu.vph‐share.euHeart.employment_details.v1 Description To record the current and past employment details of a person Keywords Employment, person, Occurrences 0…1 (optional)
Page 113 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Cardinality 0…1 (optional) References openEHR‐EHR‐CLUSTER.employment_details.v5
Current Identification of substance employment Occurrences: 1…1 (mandatory) status Cardinality: 0…1 (optional) Coded Text: Employed Employed part time Unemployed Retired Volunteer Carer Student Sick or disabled permanently Sick or disabled temporarily Current Current Occupation of the person Occupation Occurrences: 0…1 (optional) Cardinality: 0…1 (optional, non‐repeating) Free or Coded Text Date of Date of employment Employment Occurrences: 0…1 (optional) Date/Time Role/Job Role or Job Title Occurrences: 0…* (optional, repeating) Free or Coded Text Occupation Occupation Occurrences: 0…1 (optional) Free or Coded text Occupational Overview of occupational health and safety risk Health & Occurrences: 0…1 (optional) Safety Risk Cardinality: 0…* (optional, repeating, unordered) Identified Occurrences: 0…1 (optional) Risk Free or Coded Text Exposure Occurrences: 0…1 (optional) Details Free or Coded Text
V. Vital Signs A. Heart Rate
ID eu.vph‐share.euHeart.heart_rate.v1 Description The rate the heart is beating ‐ either mechanically or electrically Keywords heart rate, vital signs Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.heart_rate.v3
Page 114 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Rate The rate of the heart as beats per minute Occurrences: 0…1 (optional) Quantity (Units: Number) /min limit decimal places = 0 Rhythm The rhythm of the heart beat Occurrences: 0…1 (optional) Coded Text: Regular Irregular Irregularly irregular Description The description of the rate and rhythm Occurrences: 0…1 (optional) Free or Coded Text Position The position of the patient when the heart rate was measured Occurrences: 0…1 (optional) Coded Text: Lying Sitting Reclining Standing Device Device by which the heart rate was measured Occurrences: 0…1 (optional) Free Text
B. Blood Pressure
ID eu.vph‐share.euHeart.blood_pressure.v1 Description The measurement by any means (invasive or non‐invasive) of systemic arterial blood pressure which is deemed to represent the actual systemic blood pressure Keywords Blood, blood pressure, vital signs Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.blood_pressure.v5
Systolic Peak systemic arterial blood pressure over one cycle ‐ measured in systolic or contraction phase of the heart cycle [SNOMED‐CT: 163030003] Occurrences: 1…1 (mandatory) Quantity (Units: mm[Hg]) 0…<1000 Diastolic Minimum systemic arterial blood pressure over one cycle ‐ measured in the diastolic or relaxation phase [SNOMED‐CT: 163031004] Occurrences: 1…1 (mandatory) Quantity (Units: mm[Hg]) 0…<1000 Mean Arterial The average arterial pressure that occurs over the entire
Page 115 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Pressure course of the heart contraction and relaxation cycle ‐ calculated by (2XSBP + DBP) divided by 3. Occurrences: 0…1 (optional) Quantity (Units: mm[Hg]) 0…<750 Limit decimal places = 1 Pulse Pressure The variation in pressure over one contraction cycle Occurrences: 0…1 (optional) Quantity (Units: mm[Hg]) 0…<750 Limit decimal places = 1 Ankle Brachial A measure of the reduction in arterial blood pressure of the Pressure legs used to detect evidence of blockages (peripheral Index vascular disease). It is calculated by dividing the highest systolic blood pressure in the arteries at the ankle and foot by the higher of the two systolic blood pressures in the arms. Occurrences: 0…1 (optional) Quantity (Units: Number) >=0 limit decimal places = 1 State The position and exertion level at which the reading was taken. Occurrences: 0…1 (optional) Cardinality: 0…1 (optional) Position The position of the patient at the time of measuring blood pressure Occurrences: 1…1 (mandatory) Coded Text: Standing Sitting Reclining Lying Exertion The level of exertion at the time of taking Level the measurement Occurrences: 0…1 (optional) Quantity (Unit: J/min) 0…1000 Exercise The classification of the exercise level Occurrences: 0…1 (optional) Coded Text: At rest Post‐exercise During exercise Tilt The tilt of the surface on which the person is lying Occurrences: 0…1 (optional) Quantity (Unit: Angle) ‐90…90 History Historical readings taken at 5 and 10 minute intervals Occurrences: 0…1 (optional) Cardinality: 0…1 (optional) Baseline Baseline event in event history Occurrences: 0…1 (optional) PointInTime
Page 116 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
5 minute Blood pressure reading after 5 minutes rest reading Occurrences: 0…1 (optional) PointInTime 10 minute Blood pressure reading after 10 minutes reading rest Occurrences: 0…1 (optional) PointInTime Postural The difference between standing and Change sitting/lying blood pressure Occurrences: 0…* (optional) PointInTime Paradox Variation in blood pressure with respiration Occurrences: 0…* (optional) PointInTime Cuff Size The size of the cuff if a sphygmomanometer is used [SNOMED‐CT: 246153002] Occurrences: 0…1 (optional) Coded Text: Adult Large Adult Paediatric/Child Adult Thigh Neonatal Infant Small Adult Instrument The instrument used to measure the blood pressure [SNOMED‐CT: 57134006] Occurrences: 0…1 (optional) Free or Coded Text Location of The site of the measurement of the blood pressure measurement Occurrences: 0…1 (optional) Coded Text: Right arm Left arm Right leg Left leg Intra‐arterial Right wrist Left wrist Korotkoff Record which Korotkoff sound is used for determining sounds Diastolic pressure Coded Text: Fourth sound Fifth sound Comment Comment on blood pressure reading Occurrences: 0…1 (optional) Free or Coded Text
Page 117 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
C. Respiration
ID eu.vph‐share.euHeart.respiration.v1 Description The rate and character of breathing Keywords Respiration, vital signs Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.respiration.v7
Rate The rate of respirations Occurrences: 1…1 (mandatory) Quantity (Units: Number) /min >=0 Rhythm The rhythm of the respiration Occurrences: 0…1 (optional) Coded Text: Regular Irregular Cheyne‐Stokes Apnoeic episodes Character The character of the respirations Occurrences: 0…1 (optional) Coded Text: Gasping Grunting Kussmaul Snoring Inspiratory stridor Paradoxical breathing Recessing Nasal flare Apnoea Breathlessness Cough Excessive Secretions Wheeze None Depth Depth of respiration Occurrences: 0…1 (optional) Coded Text: Shallow Normal Deep FiO2 Fraction of inspired oxygen Occurrences: 0…1 (optional) Quantity (Unit: Percentage) % 0…100 Comments Any comments about the respiration Occurrences: 0…1 (optional) Free Text
Page 118 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
D. Body Temperature
ID eu.vph‐share.euHeart.body_temperature.v1 Description An estimate of the core temperature of the body Keywords body temperature, vital signs Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.body_temperature.v5
Temperature The core body temperature Occurrences: 1…1 (mandatory) Quantity (Units: Degree) °C °F Thermal The thermal situation of the person who is having the Situation temperature taken Occurrences: 0…1 (optional) Coded Text: Indoor ‐ normal clothing or bedding Indoor ‐ reduced clothing or bedding Indoor ‐ increased clothing or bedding Outdoors ‐ normal clothing Outdoors ‐ reduced clothing Outdoors ‐ increased clothing Thermal stress ‐ downward Thermal stress ‐ upward Paediatric incubator Naked Ambient The temperature to which the person has been exposed Temperature Occurrences: 0…1 (optional) Quantity (Units: Degree) °C °F Description of Description of the conditions applied to the patient to Thermal change temperature Stress Occurrences: 0…1 (optional) Free or Coded Text Site of The site of measurement of the temperature Measurement Occurrences: 0…1 (optional) Coded Text: Oral Aural Axilla Rectal Core Urinary bladder Intravascular Temporal
Page 119 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
VI. Substance Use A. Alcohol
ID eu.vph‐share.euHeart.substance_use_summary‐alcohol.v1 Description Archetype to record a persisting summary or overview of use or consumption of alcohol at the present time, a specific time or over a period of time. Keywords substance, addiction, consumption, use, alcohol Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐EVALUATION.substance‐alcohol.v1
Substance Identification of substance Occurrences: 1…1 (mandatory) Coded Text: Alcohol Usage Status Overview of usage of alcohol Occurrences: 1…1 (mandatory) Coded Text: Current User Former Regular User Former Occasional User Never Used Form Form of the alcohol used Occurrences: 0…1 (optional) Coded Text: All alcohol All beer All wine All spirits Full strength beer Light beer Red wine White wine Fortified wine Date Date when use commenced Commenced Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??) Date ceased Date when used ceased Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??) Standard Frequency of standard drinks of alcohol consumed Drinks Occurrences: 1…1 (mandatory) Quantity (Units: Unit) unit/h unit/d unit/wk Comment Other information of substance use Occurrences: 0…1 (optional) Free or Coded Text
Page 120 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
B. Tobacco
ID eu.vph‐share.euHeart.substance_use_summary‐tobacco.v1 Description Archetype to record a persisting summary or overview of use or consumption of tobacco at the present time, a specific time or over a period of time. Keywords substance, addiction, consumption, use, tobacco Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐EVALUATION.substance‐tobacco.v1
Substance Identification of substance Occurrences: 1…1 (mandatory) Coded Text: Tobacco Usage Status Overview of usage of tobacco Occurrences: 1…1 (mandatory) Coded Text: Current User Former Regular User Former Occasional User Never Used Form Form of the tobacco used Occurrences: 0…1 (optional) Coded Text: Cigarettes ‐ manufactured Cigarettes ‐ roll‐your‐own Cigars Pipe Date Date when use commenced Commenced Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??) Date ceased Date when used ceased Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??) Number Frequency of units containing tobacco consumed e.g. Smoked cigarettes or cigars Occurrences: 1…1 (mandatory) Quantity (Units: Unit) unit/h unit/d unit/wk Comment Other information of substance use Occurrences: 0…1 (optional) Free or Coded Text
Page 121 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
C. Caffeine
ID eu.vph‐share.euHeart.substance_use_summary‐caffeine.v1 Description Archetype to record a persisting summary or overview of use or consumption of caffeine at the present time, a specific time or over a period of time. Keywords substance, addiction, consumption, use, caffeine Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐EVALUATION.substance‐caffeine.v1
Substance Identification of substance Occurrences: 1…1 (mandatory) Coded Text: Caffeine Usage Status Overview of usage of caffeine Occurrences: 1…1 (mandatory) Coded Text: Current User Former Regular User Former Occasional User Never Used Form Form of the caffeine used Occurrences: 0…1 (optional) Coded Text: Coffee ‐ instant Coffee ‐ brewed/filtered Coffee ‐ espresso Tea Soft drink Date Date when use commenced Commenced Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??) Date ceased Date when used ceased Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??) Amount Frequency consumed ‐ only one quantity is permitted Consumed Occurrences: 0…1 (optional) Cardinality: 0…1 (optional) Cups of Consumption of coffee or tea coffee or tea Occurrences: 0…* (optional, repeating) Quantity (Units: Cups) cups/d cups/wk Shots of Consumption of espresso coffee by shots espresso Occurrences: 0…1 (mandatory) coffee Quantity (Units: Number) >=0 Volume of Consumption of caffeine‐containing soft
Page 122 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
soft drink drink by volume Occurrences: 0..* (optional, repeating) Quantity (Units: Millilitre) ml/d ml/wk Comment Other information of substance use Occurrences: 0…1 (optional) Free or Coded Text
VII. Baseline History
ID eu.vph‐share.euHeart.baseline_history.v1 Description A longitudinal record chronicling the patient's diseases, major and minor illnesses, surgical and obstetric history, medications, family history, lifestyle, social circumstances, vaccination history, growth and developmental history, etc.. In electronic healthy records this information is gained from the healthcare professional asking specific questions, of the patient or of other people who know the person and from previously recorded investigations, treatments and diagnoses. Past and current information of ongoing significance relating to past medical and surgical history. Keywords Baseline history Occurrences 1…1 (mandatory) Cardinality 1…* (mandatory, repeating, unordered) References openEHR‐EHR‐SECTION.history.v2
SECTION Include: eu.vph‐share.euHeart.cardiac_health_event.v1
VIII. Cardiac Health Event
ID eu.vph‐share. euHeart. cardiac_health_event.v1 Description A cardiac health event diagnosis defined by a clinician that is coded in an accepted terminology and may include the stage of the condition and the diagnostic criteria. Keywords Cardiac, health event Occurrences 0…1 (optional) Cardinality 0…* (optional, repeating, unordered) References openEHR‐EHR‐EVALUATION.problem‐diagnosis.v1
Diagnosis The index Diagnosis Occurrences: 1…1 (mandatory) Free Text or Choice: Angina MI Stroke Transient Ischaemic Attack CABG
Page 123 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Cirrhosis Malignancy COPD Valvular Heart Disease Hyperlipidaemia Heart Failure LVF Anaemia AF Peripheral Vascular Disease Dementia Renal Failure Diabetes State The status of the diagnosis Occurrences: 1…1 (mandatory) Coded Text: Confirmed Provisional Working Clinical Description of the clinical aspects of the problem Description Occurrences: 0…1 (optional) Free or Coded Text Severity The severity index of the problem Occurrences: 0…1 (optional) Ordinal 1. Mild 4. Moderate 7. Severe Date of last The date of last occurrence or exacerbation occurrence Occurrences: 0…1 (optional) Date/Time Family History Risk of condition based on family history Occurrences: 0…1 (optional) Include: openEHR‐EHR‐EVALUATION.risk‐family_history.v1
IX. Cardiac Imaging Study
ID eu.vph‐share.euHeart.imaging_study.v1 Description An action related to an investigation by an imaging technique. Keywords image, Xray, ultrasound, MRI, magnetic resonance, CT, scan, tomography Occurrences 1…1 (mandatory) Cardinality 1…* (mandatory, repeating, unordered) References openEHR‐EHR‐CLUSTER.imaging.v1
Clinical Clinical Findings relevant to the imaging investigations Findings Occurrences: 0…1 (optional) Free or Coded Text
Page 124 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Imaging The Type of imaging Category Occurrences: 0…1 (optional) Free or Coded Text: Xray CT scan Perfusion scan Ultrasound Echocardiogram Imaging Test Imaging test requested or performed Name Occurrences: 0…1 (optional) Free or Coded Text Study The study identifier the imaging procedure is related to Identifier Occurrences: 0…1 (optional) Identifier Anatomical The anatomical site(s) to be imaged Location Occurrences: 0…* (optional, repeating) Include: openEHR‐EHR‐CLUSTER.physical_properties.v1 and specialisations Cine Scans Real time MR movie of the heart Occurrences: 0…1 (optional) Free or Coded Text: 2Ch 3Ch 4Ch SA LVLOT 3D SSFP 3D Steady state Free Precession Images Occurrences: 0…1 (optional) Free or Coded Text CSPAM Occurrences: 0…1 (optional) Boolean Slow Occurrences: 0…1 (optional) Perfusion Boolean Early Viability Occurrences: 0…1 (optional) Boolean Late Viability Occurrences: 0…1 (optional) Boolean Measurement LVEDV Volume of blood present in the left ventricle at the end of diastole Occurrences: 0…1 (optional) Quantity (Unit: Number) ml LVEDVi Volume of blood present in the left ventricle at the end of diastole, indexed to body surface area Occurrences: 0…1 (optional) Quantity (Unit: Number) ml/m2
Page 125 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
LVESV Volume of blood present in the left ventricle at the end of systole Occurrences: 0…1 (optional) Quantity (Unit: Number) ml LVESVi Volume of blood present in the left ventricle at the end of systole, indexed to body surface area Occurrences: 0…1 (optional) Quantity (Unit: Number) ml/m2 LVSV Volume of blood ejected from the left ventricle with each contraction = LVEDV‐ LVESV Occurrences: 0…1 (optional) Quantity (Unit: Number) ml LVSVi Volume of blood ejected from the left ventricle with each contraction indexed to body surface area = LVEDV‐LVESV Occurrences: 0…1 (optional) Quantity (Unit: Number) ml/m2 LV Ejection Fraction of blood ejected from the left Fraction ventricle with each contraction versus that remaining = LVEDV‐LVESV/LVEDV Occurrences: 0…1 (optional) Quantity (Unit: Number) 0…100 RVEDV Volume of blood present in the right ventricle at the end of diastole Occurrences: 0…1 (optional) Quantity (Unit: Number) ml RVEDVi Volume of blood present in the right ventricle at the end of diastole, indexed to body surface area Occurrences: 0…1 (optional) Quantity (Unit: Number) ml/m2 RVESV Volume of blood present in the right ventricle at the end of systole Occurrences: 0…1 (optional) Quantity (Unit: Number) ml RVESVi Volume of blood present in the right ventricle at the end of systole, indexed to body surface area Occurrences: 0…1 (optional) Quantity (Unit: Number) ml/m2 RVSV Volume of blood ejected from the right ventricle with each contraction = RVEDV‐ RVESV Occurrences: 0…1 (optional) Quantity (Unit: Number) ml
Page 126 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
RVSVi Volume of blood ejected from the right ventricle with each contraction indexed to body surface area = RVEDV‐RVESV Occurrences: 0…1 (optional) Quantity (Unit: Number) ml/m2 RV Ejection Fraction of blood ejected from the right Fraction ventricle with each contraction versus that remaining = RVEDV‐RVESV/RVEDV Occurrences: 0…1 (optional) Quantity (Unit: Number) 0…100 LA Size Size of the left atrium, which may be measured in cm, mm, ml Occurrences: 0…1 (optional) Quantity (Unit: Number) cm, mm, ml RA Size Size of the right atrium, which may be measured in cm, mm, ml Occurrences: 0…1 (optional) Quantity (Unit: Number) cm, mm, ml Cure Index circumferential uniformity ratio estimate, an index of dyssynchrony, from 0‐1, with 1 = dyssynchrony Occurrences: 0…1 (optional) Quantity (Unit: Number) Late Using gadolinium contrast, an area lights up Enhancement as grey denoting an area of scar, when normally it is black Occurrences: 0…1 (optional) Boolean Site of Late Denoting the region of the ventricle Enhancement affected Occurrences: 0…1 (optional) Coded Text: Septal Anterior Lateral Inferior Posterior Apical RV LE Percent Denoting the proportion of ventricle affected Occurrences: 0…1 (optional) Quantity (Unit: Number) 0…100 View Details about a particular view Occurrences: 0…* (optional, repeating) Cardinality: 1…* (mandatory, repeating, unordered) View Name A description of the view taken
Page 127 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Occurrences: 0…1 (optional) Coded Text: SA_CINE SA SCAR SA TAGGED 3D_HEART 3D_SCAR 3D_TAGGED 4CH_TAGGED 4CH_CINE 4CH_SCAR Per View Findings related to the view taken Findings Occurrences: 0…1 (optional) Image Unique identifier of the image, normally Identifier assigned by the healthcare organisation or device. Occurrences: 1…1 (mandatory) Identifier Image Link to Multimedia Image Occurrences: 1…1 (mandatory) URI Overall Summary of imaging findings Findings Occurrences: 0…1 (optional) Free or Coded Text Imaging Information regarding the quality of the imaging that may Quality influence reporting Occurrences: 0…1 (optional) Free or Coded Text Date of The date of the imaging is to be or was carried out Imaging Occurrences: 0…1 (optional) Date/Time Location Occurrences: 0…1 (optional) Free or Coded Text
X. Medication History
ID eu.vph‐share.euHeart.medications.v1 Description For recording questions and answers about medication use. Keywords medication, history Occurrences 0…1 (optional) Cardinality 0…* (optional, repeating, unordered) References openEHR‐EHR‐EVALUATION.check_list‐medication.v3
Medication Name of medication used or previously taken Occurrences: 1…1 (mandatory) Free Text or Choice:
Page 128 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Medication ID SNOMED‐CT ID of the Medication Prescribed Occurrences: 1…1 (mandatory) Coded Text Type Occurrences: 1…1 (mandatory) Free Text or Choice: Ace Inhibitor Diuretic B Blocker Aldosterone Antagonists Statin Antiplatelet Angiotensin Inhibitor Dose Amount of drug prescribed to be taken daily Occurrences: 1…1 (mandatory) Quantity (Units: mg) /d Date Last Date the medication was last taken Used Occurrences: 0…1 (optional)
XI. Lab Test
ID eu.vph‐share.euHeart.lab_test.v1 Description To record the result of a laboratory test which may be used to record a single valued test but will often be specialised or templated to represent multiple value or 'panel' tests. This archetype also acts as the parent for specialisations appropriate for more specific laboratory tests microbiology, histopathology. Keywords lab test, history Occurrences 1…1 (mandatory) Cardinality 0…* (optional, repeating, unordered) References openEHR‐EHR‐OBSERVATION.lab_test.v1
Test Name Specific identifier for this lab test. e.g. Full blood count , blood glucose, urine microbiology. May equate to the result name for a single value result. Commonly a coded term e.g from LOINC or SNOMED‐CT. Occurrences: 0…1 (optional) Free or Coded Text Diagnostic The type of high‐level diagnostic service e.g. biochemistry, Service haematology. Occurrences: 0…1 (optional) Free or Coded Text Test Status The status of the lab test as a whole. Occurrences: 0…1 (optional) Coded Text: Interim Final Supplementatry
Page 129 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Corrected Aborted Never Performed Specimen Details of the specimen being reported where all individual Detail results are derived from the same specimen. Occurrences: 0…1 (optional) Include: eu.vph‐share.euHeart.specimen.v1 Result The result of the test. Occurrences: 0…* (optional, repeating) Free or Coded Text Per‐result Slot to allow an annotation to be added to a particular test Annotation result at run‐time. Occurrences: 0…* (optional, repeating) Include: openEHR‐EHR‐CLUSTER.lab_result.annotation.v1 Overall An overall interpretative comment on this test. Interpretation Occurrences: 0…1 (optional) Free or Coded Text Multimedia Representations of the whole test in multimedia e.g. image, Representatio audio, video. n Occurrences: 0…* (optional, repeating) Link
XII. Urine Test
ID eu.vph‐share.euHeart.lab_test‐urine.v1 Description To record the result of a urine laboratory test , Keywords lab test, history Occurrences 1…1 (mandatory) Cardinality 0…* (optional, repeating, unordered) References eu.vph‐share.euHeart.lab_test.v1
Sodium Sodium Concentration Occurrences: 0…1 (optional) Quantity (Units mmol/l) >=0 Potassium Potassium Concentration Occurrences: 0…1 (optional) Quantity (Units mmol/l) >=0 Chlorine Chlorine Concentration Occurrences: 0…1 (optional) Quantity (Units mmol/l) >=0 BiCarbonate BiCarbonate Concentration Occurrences: 0…1 (optional) Quantity (Units mmol/l) >=0 Urea Urea Concentration Occurrences: 0…1 (optional)
Page 130 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Quantity (Units mmol/l) >=0 Creatinine Creatinine Concentration Occurrences: 0…1 (optional) Quantity (Units μmol/l) >=0 Calcium Calcium Concentration Occurrences: 0…1 (optional) Quantity (Units mmol/l) >=0 * Calcium Occurrences: 0…1 (optional) Quantity (Units mmol/l) >=0 Na/K Ratio Sodium – Potassium Concentration Ratio Occurrences: 0…1 (optional) Quantity (Fraction) Albumin/Crea Occurrences: 0…1 (optional) tinine Coded Text Falied Passed Albumin Albumin Concentration Occurrences: 0…1 (optional) Quantity (Units mg/l) >=0
XIII. Blood Test
ID eu.vph‐share.euHeart.lab_test‐blood.v1 Description To record the result of a laboratory test , Keywords lab test, history, blood, hematology Occurrences 1…1 (mandatory) Cardinality 0…* (optional, repeating, unordered) References eu.vph‐share.euHeart.lab_test.v1
Pulmonary To record the concentration levels of a chmiec Function Prot Occurrences: 0…1 (optional) Quantity (Units mmol/l) >=0 Alb Level of Albumin Occurrences: 0…1 (optional) Quantity (Units mmol/l) >=0 GLO Level of Globulin Occurrences: 0…1 (optional) Quantity (Units mmol/l) >=0 AST Level of Aspartate Amino‐Transferase = (normal) 10‐45IU/L Occurrences: 0…1 (optional) Quantity (Units mmol/l) >=0 ALP Occurrences: 0…1 (optional) Quantity (Units mmol/l) >=0 ALT Level of Alanine Amino‐ Transferase =
Page 131 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
(normal) 10‐50IU/L Occurrences: 0…1 (optional) Quantity (Units μmol/l) >=0 GGT Level of Gamma‐Glutamyl‐ Transferase = (normal) 10‐55 (male) and 5‐35 (female) IU/L Occurrences: 0…1 (optional) Quantity (Units mmol/l) >=0 Bili Level of Bilirubin Occurrences: 0…1 (optional) Quantity (Units mmol/l) >=0 Glu Random = A non‐fasting measurement of venous blood glucose (normal) < 11.1mmol/l Fasting = A overnight starved measurement of venous blood glucose (normal) 3.6‐ 5.8mmol/l Occurrences: 0…1 (optional) Quantity (Fraction) Coagulation Level of Coagulation Occurrences: 0…1 (optional) Cardinality: 0…1 (optional) Aptt A measure of the intrinsic pathway of coagulation = (normal) 25‐40seconds Occurrences: 0…1 (optional) Quantity (Units: seconds) INR Internationalised Normal Ratio – the ratio of the patient's prothrombin time to a control (which is normal) sample, raised to the power of the International Sensitvity Index value for the system used = (normal) 0.8‐1.2s. Occurrences: 0…1 (optional) Quantity (Units: seconds) Pt A measure of the extrinisic pathway of coagulation = (normal) 12‐15s Occurrences: 0…1 (optional) Quantity (Units: seconds) Endocrine Level of Endocrine Production Occurrences: 0…1 (optional) Cardinality: 0…1 (optional) TSH Level of Thyroid Stimulating Hormone Occurrences: 0…1 (optional) Quantity (Units: mLU/l) Free T3 Occurrences: 0…1 (optional) Quantity (Units: Pmol/l) PTH Occurrences: 0…1 (optional)
Page 132 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Quantity (Units: Pg/ml) Inflammatory Level of Inflammatory Markers markers Occurrences: 0…1 (optional) Cardinality: 0…1 (optional) hsCRP Level of High sensitivity C‐Reactive Protien Occurrences: 0…1 (optional) Quantity (Units: mg/l) Uric Acid Level of Uric Acid Occurrences: 0…1 (optional) Quantity (Units: Mg/dl) Cardiac Level of Cardiac Markers Markers Occurrences: 0…1 (optional) Cardinality: 0…1 (optional) BNP Level of B‐Type Natriuretic Peptide Occurrences: 0…1 (optional) Quantity (Units:) >=0.0 Troponin I Level of Troponin I Occurrences: 0…1 (optional) Quantity (Units: μg/l)
XIV. ECG Recording
ID eu.vph‐share.euHeart.ecg.v1 Description An electrocardiograph (ECG or EKG) is an interpretation of the electrical activity of the heart over time, recorded non‐invasively using external skin electrodes.To record the electrocardiographic interpretation of the electrical activity of the heart by an ECG device. Keywords electrocardiograph, ECG, EKG, electrocardiogram, electrocardiography, 12 lead Occurrences 0…1 (optional) Cardinality 0…* (optional, repeating, unordered) References openEHR‐EHR‐OBSERVATION.ecg.v1
Global ECG Details about the entire ECG Parameters Occurrences: 0…1 (optional) Cardinality: 1…* (mandatory, repeating, unordered) RR Rate OccurrencesRR is the interval from the onset of one QRS complex to the onset of the next QRS complex Occurrences: 0…1 (optional) Frequency (Units: Number) >= 0.0 /min PR Interval The PR interval is measured from the beginning of the P wave to the beginning of the QRS complex. Occurrences: 0…1 (optional) Frequency (Units: Number) >= 0.0 /millisec
Page 133 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
QRS Interval The QRS complex reflects the rapid depolarization of the right and left ventricles. Occurrences: 0…1 (optional) Frequency (Units: Number) >= 0.0 /millisec QT Interval The QT interval is measured from the beginning of the QRS complex to the end of the T wave Occurrences: 0…1 (optional) Frequency (Units: Number) >= 0.0 /millisec QTC Interval QTc is the QT interval corrected for heart rate Occurrences: 0…1 (optional) Frequency (Units: Number) >= 0.0 /millisec Axis Wave axis depolarisation Occurrences: 0…1 (optional) Cardinality: 0…1 (optional) P Axis P wave axis Occurrences: 0…1 (optional) Angle (Units: Degrees) QRS Axis QRS complex wave axis Occurrences: 0…1 (optional) Angle (Units: Degrees) T Axis T wave axis Occurrences: 0…1 (optional) Angle (Units: Degrees) Per‐lead Details about measured parameters for each named lead Parameters (specified in the run‐time name constraint). Occurrences: 0…12 (optional) Cardinality 1…* (mandatory, repeating, unordered) Lead Name Lead Name Occurrences: 1…1 (mandatory) Coded Text: Lead I Lead II Lead III Lead aVR Lead aVL Lead aVF Lead V1 Lead V2 Lead V3 Lead V4 Lead V5 Lead V6 P Amplitude P wave amplitude Occurrences: 0…1 (optional) Quantity (Units: mV)
Page 134 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
P Duration Duration of P wave Occurrences: 0…1 (optional) Quantity (Units: Time) >=0.0 millisec P Area P wave area for monophasic P waves or the area of the initial portion of a biphasic P wave Occurrences: 0…1 (optional) Quantity (Units: Ashman) P’ Amplitude P’ wave amplitude Occurrences: 0…1 (optional) Quantity (Units: mV) P’ Duration Duration of P’ wave Occurrences: 0…1 (optional) Quantity (Units: Time) >=0.0 millisec P’ Area P’ wave area for monophasic P’ waves or the area of the initial portion of a biphasic P wave Occurrences: 0…1 (optional) Quantity (Units: Ashman) Q Amplitude Q wave amplitude Occurrences: 0…1 (optional) Quantity (Units: mV) Q Duration Duration of Q wave Occurrences: 0…1 (optional) Quantity (Units: Time) >=0.0 millisec R Amplitude R wave amplitude Occurrences: 0…1 (optional) Quantity (Units: mV) R Duration Duration of R wave Occurrences: 0…1 (optional) Quantity (Units: Time) >=0.0 millisec S Amplitude S wave amplitude Occurrences: 0…1 (optional) Quantity (Units: mV) S Duration Duration of S wave Occurrences: 0…1 (optional) Quantity (Units: Time) >=0.0 millisec R’ Amplitude R’ wave amplitude Occurrences: 0…1 (optional) Quantity (Units: mV) R’ Duration Duration of R’ wave Occurrences: 0…1 (optional) Quantity (Units: Time) >=0.0 millisec S’ Amplitude S’ wave amplitude Occurrences: 0…1 (optional) Quantity (Units: mV) S’ Duration Duration of S’ wave
Page 135 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Occurrences: 0…1 (optional) Quantity (Units: Time) >=0.0 millisec V.A.T Ventricular Activation Time is the interval from the onset of the QRS complex to the latest positive peak in the complex, or the latest substantial notch on the latest peak (whichever is later). Occurrences: 0…1 (optional) Quantity (Units: Time) >=0.0 millisec QRS p‐p Peak‐To‐Peak QRS complex amplitude Occurrences: 0…1 (optional) Quantity (Units: mV) QRS QRS complex duration, measured from its Duration onset to the ST segment onset (J point). Occurrences: 0…1 (optional) Quantity (Units: Time) >=0.0 millisec QRS Area The area of the QRS complex. Occurrences: 0…1 (optional) Quantity (Units: Ashman) ST onset Elevation or depression at the onset (J point) of the ST segment. Occurrences: 0…1 (optional) Quantity (Units: mV) ST midpoint Elevation or depression at the midpoint of the ST segment. Occurrences: 0…1 (optional) Quantity (Units: mV) ST 80ms Elevation or depression of the ST segment 80 ms after the end of the QRS complex (J point). Occurrences: 0…1 (optional) Quantity (Units: mV) ST end Elevation or depression at the end of the ST segment. Occurrences: 0…1 (optional) Quantity (Units: mV) ST Duration ST segment duration. Occurrences: 0…1 (optional) Quantity (Units: Time) >=0.0 millisec ST Slope ST segment slope. Slope is measured in degrees for 25 mm/sec, 1mV/cm scaling. Occurrences: 0…1 (optional) Quantity (Units: Angle) ‐90…90 ST Shape The ST segment shape. Occurrences: 0…1 (optional) Free or Coded Text Straight
Page 136 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Concave Upward Concave Downward T Amplitude T Wave Amplitude Occurrences: 0…1 (optional) Quantity (Units: mV) T Duration T wave duration Occurrences: 0…1 (optional) Quantity (Units: Time) >=0.0 millisec T Area The area of the T wave Occurrences: 0…1 (optional) Quantity (Units: Ashman) Automatic Interpretative comment on this recording originating from Interpretation the device. Occurrences: 0…1 (optional) Free or Coded Text Overall An overall interpretative comment on this recording. Interpretation Occurrences: 0…1 (optional) Free or Coded Text ECG Recording Multimedia representation of the ECG. Occurrences: 0…1 (optional) Free or Coded Text ECG Device Details about the electrocardiograph device used to record the ECG. Occurrences: 0…1 (optional) Include: openEHR‐EHR‐CLUSTER.device.v1 QTc Method used to correct QT interval Calculation Occurrences: 0…1 (optional) Method Free or Coded Text
XV. Hand Grip Strength
ID eu.vph‐share.euHeart.hand_grip_strength.v1 Description A recording of hand grip strength. Keywords Hand grip, fitness Occurrences 0…1 (optional) Cardinality 0…* (optional, repeating, unordered) References
Left Hand Grip Measurements about the left hand grip strength Occurrences: 0…1 (optional) Cardinality: 1…* (mandatory, repeating, unordered) Quantity (Units: kg) Right Hand Measurements about the right hand grip strength Grip Occurrences: 0…1 (optional) Cardinality: 1…* (mandatory, repeating, unordered) Quantity (Units: kg)
Page 137 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Left Hand Mean Measurements about the left hand grip strength Mean Occurrences: 1…1 (madatory) Measurement Cardinality: 1…1 (mandatory, repeating, unordered) Quantity (Units: kg) Right Hand Mean Measurements about the right hand grip strength Mean Occurrences: 1…1 (madatory) Measurement Cardinality: 1…1 (mandatory, repeating, unordered) Quantity (Units: kg)
XVI. Pulmonary Function
ID eu.vph‐share.euHeart.pulmonary_function.v1 Description A recoding of pulmonary function. Keywords Pulmonary function, heart Occurrences 0…1 (optional) Cardinality 0…* (optional, repeating, unordered) References
Resting HR Occurrences: 0…1 (optional) Quantity Peak HR Occurrences: 0…1 (optional) Quantity Resting BP Occurrences: 0…1 (optional) Quantity Peak BP Occurrences: 0…1 (optional) Quantity Resting O2 Occurrences: 0…1 (optional) sats Quantity Peak O2 sats Occurrences: 0…1 (optional) Quantity Increase in Occurrences: 0…1 (optional) Work Quantity Peak Work Occurrences: 0…1 (optional) Quantity Exercise Occurrences: 0…1 (optional) Duration(m s) Quantity % predicted Occurrences: 0…1 (optional) Quantity VO2 max Occurrences: 0…1 (optional) Quantity BORG Scale Occurrences: 0…1 (optional) (1‐10) Quantity Peak O2 Occurrences: 0…1 (optional) Consumption Quantity Perceived Occurrences: 0…1 (optional) Exertion (6‐ Quantity
Page 138 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
20) % Predicted Occurrences: 0…1 (optional) Quantity Anaerobic Occurrences: 0…1 (optional) Threshold Quantity Comments Occurrences: 0…1 (optional) Free or Coded Text
XVII. Imaging Details
ID eu.vph‐share.euHeart.imaging_details.v1 Description Details of imaging, used in requests for imaging, records of imaging procedures and imaging reports. Keywords image, mri, x‐ray, Occurrences 1…1 (mandatory) Cardinality 1…* (mandatory, repeating, unordered) References openEHR‐EHR‐CLUSTER.imaging.v1
Imaging The Type of imaging Category Occurrences: 0…1 (optional) Free or Coded Text Imaging Test Imaging test requested or performed Name Occurrences: 0…1 (optional) Free or Coded Text Study The identifier related to the particular study Identifier Occurrences: 0…1 (optional) Identifier Anatomical The anatomical site(s) to be imaged Location Occurrences: 0…* (optional, repeating) Include: openEHR‐EHR‐CLUSTER.physical_properties.v1 and specialisations View Details about a particular view Occurrences: 0…* (optional, repeating) Cardinality: 1…* (mandatory, repeating, unordered) View Name A description of the view taken Occurrences: 0…1 (optional) Per View Findings related to the view taken Findings Occurrences: 0…1 (optional) Image Unique identifier of the image, normally Identifier assigned by the healthcare organisation or device. Occurrences: 1…1 (mandatory) Identifier Image Link to Multimedia Image Occurrences: 1…1 (mandatory) URI
Page 139 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Overall Summary of imaging findings Findings Occurrences: 0…1 (optional) Free or Coded Text Imaging Information regarding the quality of the imaging that may Quality influence reporting Occurrences: 0…1 (optional) Free or Coded Text
Page 140 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
ANNEX 7: VIROLAB PATIENT AVATAR I. Patient Demographic Data
ID eu.vph‐share.viroLab.person_details.v1 Description Demographic data about a person such as birth data, sex, height, weight and ethnic group Keywords demographic service, person identifier, person's demographic data Occurrences 1…1 (mandatory) Cardinality 1…1 (mandatory) References DEMOGRAPHIC‐ITEM_TREE.person_details.v1
Patient ID The combination of identifier type, identifier issuer and identifier name that specify the link between this name and reporting or other unique identifier usage. Occurrences: 1…1 (mandatory) Identifier Birth Date The date of birth of a person Occurrences: 1…1 (mandatory) Date Sex The sex of the person Occurrences: 1…1 (mandatory) Coded Text: Male Female Intersex/Indeterminate Height The height of the person Occurrences: 1…1 (mandatory) Quantity (Units: cm) Weight The weight of the person Occurrences: 1…1 (mandatory) Quantity (Units: kg) Ethnic The person’s ethnic background Background Occurrences: 0…* (optional) Free or Coded Text
II. Personal and Social history
ID eu.vph‐share.viroLab.personal_and_social_history.v1 Description Record the personal and social circumstances of the person Keywords Person, social history, ethnicity, marital status, Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.personal_and_social_history.v4
Maternal Ethnic background of mother Ethnicity Occurrences: 0…1 (optional)
Page 141 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Coded Text: White ‐ British White ‐ Irish White ‐ other Mixed ‐ white and black Caribbean Mixed ‐ white and black African Mixed ‐ white and Asian Mixed ‐ other Asian/Asian British ‐ Indian Asian/Asian British ‐ Pakistani Asian/Asian British ‐ Bangladeshi Asian/Asian British ‐ other Asian Chinese Paternal Ethnic background of father Ethnicity Occurrences: 0…1 (optional) Coded Text: White ‐ British White ‐ Irish White ‐ other Mixed ‐ white and black Caribbean Mixed ‐ white and black African Mixed ‐ white and Asian Mixed ‐ other Asian/Asian British ‐ Indian Asian/Asian British ‐ Pakistani Asian/Asian British ‐ Bangladeshi Asian/Asian British ‐ other Asian Chinese Marital Status Marital Status Occurrences: 0…1 (optional) Coded Text: Widowed Divorced Separated Married (incl. civil partnership and common‐law) Partner Single ‐ supported Single ‐ unsupported Household Description of others with whom the subject resides Composition Occurrences: 0…1 (optional) Coded Text: Sole parent with dependant(s) only Couple only Couple with dependant(s) only Family (with non‐related member(s) present) Family (with other family member(s) present) Group (unrelated adults)
Page 142 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Single (person living alone) Type of The setting in which the person lives Accommodati Occurrences: 0…1 (optional) on Coded Text Private residence, including privately and publicly rented homes Psychiatric hospital Specialised alcohol/other drug treatment residence Specialised mental health community‐based residential support service Domestic‐scale supported living facility Boarding/rooming house/hostel or hostel type accommodation, not including aged persons' hostel Homeless persons' shelter Shelter/refuge (not including homeless persons' shelter) Other supported accommodation Prison/remand centre/youth training centre Public place (homeless) Zone of The geographic zone of residence Residence Occurrence: 0…1 (optional) Free or Coded Text Country of Country or origin Origin Occurrence: 0…1 (optional) Coded Text
III. Fitness and Lifestyle
ID eu.vph‐share.viroLab.lifestyle.v1 Description A short object to capture basic details about a person's lifestyle, diet, etc. Keywords person, activity, fitness, diet Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.lifestyle.v3
Activity Level Occurrences: 0…1 (optional) Coded Text: Active Semi‐Active Sedentary Fitness Level Occurrences: 0…1 (optional) Coded Text: Fit Unfit Type of Occurrences: 0…1 (optional) Exercise Free or Coded Text Frequency Occurrences: 0…1 (optional) Quantity (Units: Number)
Page 143 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
/d /yr /wk Average Occurrences: 0…1 (optional) Duration Quantity (Units: Number) hours, months Diet Occurrences: 0…1 (optional) Coded Text: Normal Vegetarian Vegan Lactose free Gluten free Special Diet Details Occurrences: 0…1 (optional) Free or Coded Text
IV. Sexual Health
ID eu.vph‐share.viroLab.sexual_health.v1 Description A short object to capture basic details about a person's sexual health and lifestyle. Keywords person, sexual activity Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.lifestyle.v3
HIV Status HIV Status Occurrences: 0…1 (mandatory) Coded Text: Positive Negative Previously Positive Date of First Date of first HIV presentation HIV positive Occurrences: 0…1 (optional) Test Date (yyyy‐mm‐dd) Mode of HIV Mode of HIV Transmission Transmission Occurrences: 0…1 (optional) Coded Text: men having sex with men (MSM) hetero‐ sexual intravenous drug user (IDU) blood products other/unknown Antiretroviral Status of antiretroviral therapy Therapy Occurrences: 0…1 (optional) Status Coded Text: ART‐experienced
Page 144 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
ART‐naive Seroconversio Media Time between last HIV negative test and first HIV n year positive test Occurrences: 0…1 (optional) Date (yyyy‐mm‐dd)
V. Employment Details
ID eu.vph‐share.viroLab.employment_details.v1 Description To record the current and past employment details of a person Keywords substance, addiction, consumption, use, alcohol Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐CLUSTER.employment_details.v5
Current Identification of substance employment Occurrences: 1…1 (mandatory) status Cardinality: 0…1 (optional) Coded Text: Employed Employed part time Unemployed Retired Volunteer Carer Student Sick or disabled permanently Sick or disabled temporarily Current Current Occupation of the person Occupation Occurrences: 0…1 (optional) Cardinality: 0…1 (optional, non‐repeating) Free or Coded Text Date of Occurrences: 0…1 (optional) Employment Date/Time Role/Job Occurrences: 0…* (optional, repeating) Free or Coded Text Occupation Occurrences: 0…1 (optional) Free or Coded text Occupational Overview of occupational health and safety risk Health & Occurrences: 0…1 (optional) Safety Risk Cardinality: 0…* (optional, repeating, unordered) Identified Occurrences: 0…1 (optional) Risk Free or Coded Text Exposure Occurrences: 0…1 (optional) Details Free or Coded Text
Page 145 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
VI. Vital Signs A. Heart Rate
ID eu.vph‐share.viroLab.heart_rate.v1 Description The rate the heart is beating ‐ either mechanically or electrically Keywords heart rate, vital signs Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.heart_rate.v3
Rate The rate of the heart as beats per minute Occurrences: 0…1 (optional) Quantity (Units: Number) /min limit decimal places = 0 Rhythm The rhythm of the heart beat Occurrences: 0…1 (optional) Coded Text: Regular Irregular Irregularly irregular Description The description of the rate and rhythm Occurrences: 0…1 (optional) Free or Coded Text Position The position of the patient when the heart rate was measured Occurrences: 0…1 (optional) Coded Text: Lying Sitting Reclining Standing Device Device by which the heart rate was measured Occurrences: 0…1 (optional) Free Text
B. Blood Pressure
ID eu.vph‐share.viroLab.blood_pressure.v1 Description The measurement by any means (invasive or non‐invasive) of systemic arterial blood pressure which is deemed to represent the actual systemic blood pressure Keywords Blood, blood pressure, vital signs Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.blood_pressure.v5
Systolic Peak systemic arterial blood pressure over one cycle ‐
Page 146 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
measured in systolic or contraction phase of the heart cycle [SNOMED‐CT: 163030003] Occurrences: 1…1 (mandatory) Quantity (Units: mm[Hg]) 0…<1000 Diastolic Minimum systemic arterial blood pressure over one cycle ‐ measured in the diastolic or relaxation phase [SNOMED‐CT: 163031004] Occurrences: 1…1 (mandatory) Quantity (Units: mm[Hg]) 0…<1000 Mean Arterial The average arterial pressure that occurs over the entire Pressure course of the heart contraction and relaxation cycle ‐ calculated by (2XSBP + DBP) divided by 3. Occurrences: 0…1 (optional) Quantity (Units: mm[Hg]) 0…<750 Limit decimal places = 1 Pulse Pressure The variation in pressure over one contraction cycle Occurrences: 0…1 (optional) Quantity (Units: mm[Hg]) 0…<750 Limit decimal places = 1 Ankle Brachial A measure of the reduction in arterial blood pressure of the Pressure legs used to detect evidence of blockages (peripheral Index vascular disease). It is calculated by dividing the highest systolic blood pressure in the arteries at the ankle and foot by the higher of the two systolic blood pressures in the arms. Occurrences: 0…1 (optional) Quantity (Units: Number) >=0 limit decimal places = 1 State The position and exertion level at which the reading was taken. Occurrences: 0…1 (optional) Cardinality: 0…1 (optional) Position The position of the patient at the time of measuring blood pressure Occurrences: 1…1 (mandatory) Coded Text: Standing Sitting Reclining Lying Exertion The level of exertion at the time of taking Level the measurement Occurrences: 0…1 (optional) Quantity (Unit: J/min) 0…1000 Exercise The classification of the exercise level Occurrences: 0…1 (optional) Coded Text: At rest Post‐exercise During exercise
Page 147 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Tilt The tilt of the surface on which the person is lying Occurrences: 0…1 (optional) Quantity (Unit: Angle) ‐90…90 History Historical readings taken at 5 and 10 minute intervals Occurrences: 0…1 (optional) Cardinality: 0…1 (optional) Baseline Baseline event in event history Occurrences: 0…1 (optional) PointInTime 5 minute Blood pressure reading after 5 minutes rest reading Occurrences: 0…1 (optional) PointInTime 10 minute Blood pressure reading after 10 minutes reading rest Occurrences: 0…1 (optional) PointInTime Postural The difference between standing and Change sitting/lying blood pressure Occurrences: 0…* (optional) PointInTime Paradox Variation in blood pressure with respiration Occurrences: 0…* (optional) PointInTime Cuff Size The size of the cuff if a sphygmomanometer is used [SNOMED‐CT: 246153002] Occurrences: 0…1 (optional) Coded Text: Adult Large Adult Paediatric/Child Adult Thigh Neonatal Infant Small Adult Instrument The instrument used to measure the blood pressure [SNOMED‐CT: 57134006] Occurrences: 0…1 (optional) Free or Coded Text Location of The site of the measurement of the blood pressure measurement Occurrences: 0…1 (optional) Coded Text: Right arm Left arm Right leg Left leg Intra‐arterial
Page 148 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Right wrist Left wrist Korotkoff Record which Korotkoff sound is used for determining sounds Diastolic pressure Coded Text: Fourth sound Fifth sound Comment Comment on blood pressure reading Occurrences: 0…1 (optional) Free or Coded Text
C. Respiration
ID eu.vph‐share.viroLab.repiration.v1 Description The rate and character of breathing Keywords Respiration, vital signs Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.respiration.v7
Rate The rate of respirations Occurrences: 1…1 (mandatory) Quantity (Units: Number) /min >=0 Rhythm The rhythm of the respiration Occurrences: 0…1 (optional) Coded Text: Regular Irregular Cheyne‐Stokes Apnoeic episodes Character The character of the respirations Occurrences: 0…1 (optional) Coded Text: Gasping Grunting Kussmaul Snoring Inspiratory stridor Paradoxical breathing Recessing Nasal flare Apnoea Breathlessness Cough Excessive Secretions Wheeze None
Page 149 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Depth Depth of respiration Occurrences: 0…1 (optional) Coded Text: Shallow Normal Deep FiO2 Fraction of inspired oxygen Occurrences: 0…1 (optional) Quantity (Unit: Percentage) % 0…100 Comments Any comments about the respiration Occurrences: 0…1 (optional) Free Text
D. Body Temperature
ID eu.vph‐share.viroLab.body_temperature.v1 Description An estimate of the core temperature of the body Keywords body temperature, vital signs Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.body_temperature.v5
Temperature The core body temperature Occurrences: 1…1 (mandatory) Quantity (Units: Degree) °C °F Thermal The thermal situation of the person who is having the Situation temperature taken Occurrences: 0…1 (optional) Coded Text: Indoor ‐ normal clothing or bedding Indoor ‐ reduced clothing or bedding Indoor ‐ increased clothing or bedding Outdoors ‐ normal clothing Outdoors ‐ reduced clothing Outdoors ‐ increased clothing Thermal stress ‐ downward Thermal stress ‐ upward Paediatric incubator Naked Ambient The temperature to which the person has been exposed Temperature Occurrences: 0…1 (optional) Quantity (Units: Degree) °C °F Description of Description of the conditions applied to the patient to Thermal change temperature Stress Occurrences: 0…1 (optional) Free or Coded Text Site of The site of measurement of the temperature
Page 150 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Measurement Occurrences: 0…1 (optional) Coded Text: Oral Aural Axilla Rectal Core Urinary bladder Intravascular Temporal
VII. Substance Use A. Alcohol
ID eu.vph‐share.viroLab.substance_use_summary‐alcohol.v1 Description Archetype to record a persisting summary or overview of use or consumption of alcohol at the present time, a specific time or over a period of time. Keywords substance, addiction, consumption, use, alcohol Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐EVALUATION.substance‐alcohol.v1
Substance Identification of substance Occurrences: 1…1 (mandatory) Coded Text: Alcohol Usage Status Overview of usage of alcohol Occurrences: 1…1 (mandatory) Coded Text: Current User Former Regular User Former Occasional User Never Used Form Form of the alcohol used Occurrences: 0…1 (optional) Coded Text: All alcohol All beer All wine All spirits Full strength beer Light beer Red wine White wine Fortified wine Date Date when use commenced Commenced Occurrences: 0…1 (optional)
Page 151 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Date: (Unit: yyyy‐??‐??) Date ceased Date when used ceased Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??) Standard Frequency of standard drinks of alcohol consumed Drinks Occurrences: 1…1 (mandatory) Quantity (Units: Unit) unit/h unit/d unit/wk Comment Other information of substance use Occurrences: 0…1 (optional) Free or Coded Text B. Tobacco
ID eu.vph‐share.viroLab.substance_use_summary‐tobacco.v1 Description Archetype to record a persisting summary or overview of use or consumption of tobacco at the present time, a specific time or over a period of time. Keywords substance, addiction, consumption, use, tobacco Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐EVALUATION.substance‐tobacco.v1
Substance Identification of substance Occurrences: 1…1 (mandatory) Coded Text: Tobacco Usage Status Overview of usage of tobacco Occurrences: 1…1 (mandatory) Coded Text: Current User Former Regular User Former Occasional User Never Used Form Form of the tobacco used Occurrences: 0…1 (optional) Coded Text: Cigarettes ‐ manufactured Cigarettes ‐ roll‐your‐own Cigars Pipe Date Date when use commenced Commenced Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??) Date ceased Date when used ceased Occurrences: 0…1 (optional)
Page 152 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Date: (Unit: yyyy‐??‐??) Number Frequency of units containing tobacco consumed e.g. Smoked cigarettes or cigars Occurrences: 1…1 (mandatory) Quantity (Units: Unit) unit/h unit/d unit/wk Comment Other information of substance use Occurrences: 0…1 (optional) Free or Coded Text
C. Caffeine
ID eu.vph‐share.viroLab.substance_use_summary‐caffeine.v1 Description Archetype to record a persisting summary or overview of use or consumption of caffeine at the present time, a specific time or over a period of time. Keywords substance, addiction, consumption, use, caffeine Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐EVALUATION.substance‐caffeine.v1
Substance Identification of substance Occurrences: 1…1 (mandatory) Coded Text: Caffeine Usage Status Overview of usage of caffeine Occurrences: 1…1 (mandatory) Coded Text: Current User Former Regular User Former Occasional User Never Used Form Form of the caffeine used Occurrences: 0…1 (optional) Coded Text: Coffee ‐ instant Coffee ‐ brewed/filtered Coffee ‐ espresso Tea Soft drink Date Date when use commenced Commenced Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??) Date ceased Date when used ceased Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??)
Page 153 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Amount Frequency consumed ‐ only one quantity is permitted Consumed Occurrences: 0…1 (optional) Cardinality: 0…1 (optional) Cups of Consumption of coffee or tea coffee or tea Occurrences: 0…* (optional, repeating) Quantity (Units: Cups) cups/d cups/wk Shots of Consumption of espresso coffee by shots espresso Occurrences: 0…1 (optional) coffee Quantity (Units: Number) >=0 Volume of Consumption of caffeine‐containing soft soft drink drink by volume Occurrences: 0..* (optional, repeating) Quantity (Units: Millilitre) ml/d ml/wk Comment Other information of substance use Occurrences: 0…1 (optional) Free or Coded Text
VIII. Specimen
ID eu.vph‐share.viroLab.specimen.v1 Description To record details of a laboratory specimen. Will often be used in different contexts e.g within an Instruction archetype to describe the specimen that has to be taken, or describing the specimen which accompanies the laboratory request. It may occur within an Action archetype e.g. describing specimens taken as part of a surgical procedure. Keywords specimen Occurrences 1…1 (mandatory) Cardinality 1…* (mandatory, repeating, unordered) References openEHR‐EHR‐CLUSTER.specimen.v1
Specimen Unique identifier of the specimen, normally assigned by the Identifier laboratory. Occurrences: 1…1 (mandatory) Identifier Specimen The type of specimen to be collected e.g. venous blood, Tissue Type prostatic biopsy. Occurrences: 0…1 (optional) Free or Coded Text Collection The method of collection to be used e.g. Venepuncture, Procedure biopsy, resection. Occurrences: 0…1 (optional) Free or Coded Text
Page 154 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Site The anatomical site(s) from where the specimen was taken. Occurrences: 0…* (optional, repeating) Include: openEHR‐EHR‐CLUSTER.physical_properties.v1 and specialisations Physical Dimensions / weight of sample. Set as unbounded to allow Details variations e.g Weight of prostatic gland with and without seminal vesicles Occurrences: 0…* (optional, repeating) Include: openEHR‐EHR‐CLUSTER.physical_properties.v1 and specialisations Date and Time The date and time that collection has been ordered to take of Collection place or has taken place. Occurrences: 0…1 (optional) Date/Time
IX. Viral DNA Sequence Specimen
ID eu.vph‐share.viroLab.specimen.v1 Description To record details of a DNA specimen. Keywords Specimen, dna Occurrences 1…1 (mandatory) Cardinality 1…* (mandatory, repeating, unordered) References openEHR‐EHR‐CLUSTER.specimen.v1
Sequence Unique identifier of the DNA sequence, normally assigned Identifier by the laboratory. Occurrences: 1…1 (mandatory) Identifier Specimen The type of DNA to be collected. Tissue Type Occurrences: 1…1 (mandatory) Coded Text: DNA Collection The method of collection to be used to collect DNA Procedure Occurrences: 0…1 (optional) Free or Coded Text Site The anatomical site(s) from where the specimen was taken. Occurrences: 0…* (optional, repeating) Include: openEHR‐EHR‐CLUSTER.physical_properties.v1 and specialisations Physical Dimensions / weight of sample. Set as unbounded to allow Details variations e.g. Weight of prostatic gland with and without seminal vesicles Occurrences: 0…* (optional, repeating) Include: openEHR‐EHR‐CLUSTER.physical_properties.v1 and specialisations Date and Time The date and time that collection has been ordered to take of Collection place or has taken place.
Page 155 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Occurrences: 0…1 (optional) Date/Time Findings Viral DNA sequencing findings Occurrences: 0…1 (optional) Cardinality: 0…* (optional, repeating, unordered) HIV Viral HIV Viral Subtype Subtype Occurrences: 0…1 (optional) Coded Text: HIV‐1 M‐A HIV‐1 M‐B HIV‐1 M‐C HIV‐1 M‐D HIV‐1 M‐E HIV‐1 M‐F HIV‐1 M‐G HIV‐1 M‐H HIV‐1 M‐I HIV‐1 M‐J HIV‐1 M‐K HIV‐1 CRF‐(A…K/A…K) HIV‐1 N HIV‐1 O HIV‐1 P HIV‐2 Plasma HIV‐ Plasma HIV‐RNA load RNA Load Occurrences: 0…1 (optional) Quantity (Number) /ml CD4+ Cell CD4+ Cell count Count Occurrences: 0…1 (optional) Quantity (Number) Mutations Mutations present on nucleoside‐tide/non‐ nucleoside reverse transcriptase inhibitors and protease inhibitors Occurrences: 0…1 (optional) Coded Text: NRTI nNRTI PI RNA RNA sequence information encompassed sequence the HIV pol gene region, covering the whole protease and most of the reverse transcriptase gene.
Page 156 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
ANNEX 8: VPHOP PATIENT AVATAR X. Patient Demographic Data
ID eu.vph‐share.VPHOP.person_details.v1 Description Demographic data about a person such as birth data, sex, height, weight and ethnic group Keywords demographic service, person identifier, person's demographic data Occurrences 1…1 (mandatory) Cardinality 1…1 (mandatory) References openEHR.DEMOGRAPHIC‐ITEM_TREE.person_details.v1
Patient ID The combination of identifier type, identifier issuer and identifier name that specify the link between this name and reporting or other unique identifier usage. Occurrences: 1…1 (mandatory) Identifier Birth Date The date of birth of a person Occurrences: 1…1 (mandatory) Date Sex The sex of the person Occurrences: 1…1 (mandatory) Coded Text: Male Female Intersex/Indeterminate Height The height of the person Occurrences: 1…1 (mandatory) Quantity (Units: cm) Height at 25 The height of the person at age 25 Occurrences: 0…1 (optional) Quantity (Units: cm) Weight The weight of the person Occurrences: 1…1 (mandatory) Quantity (Units: kg) Weight at 25 The weight of the person at age 25 Occurrences: 0…1 (optional) Quantity (Units: kg) Ethnic The person’s ethnic background Background Occurrences: 0…* (optional) Free or Coded Text
XI. Personal and Social history
ID eu.vph‐share.VPHOP.personal_and_social_history.v1 Description Record the personal and social circumstances of the person Keywords Person, social history, ethnicity, marital status,
Page 157 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.personal_and_social_history.v4
Maternal Ethnic background of mother Ethnicity Occurrences: 0…1 (optional) Coded Text: White ‐ British White ‐ Irish White ‐ other Mixed ‐ white and black Caribbean Mixed ‐ white and black African Mixed ‐ white and Asian Mixed ‐ other Asian/Asian British ‐ Indian Asian/Asian British ‐ Pakistani Asian/Asian British ‐ Bangladeshi Asian/Asian British ‐ other Asian Chinese Paternal Ethnic background of father Ethnicity Occurrences: 0…1 (optional) Coded Text: White ‐ British White ‐ Irish White ‐ other Mixed ‐ white and black Caribbean Mixed ‐ white and black African Mixed ‐ white and Asian Mixed ‐ other Asian/Asian British ‐ Indian Asian/Asian British ‐ Pakistani Asian/Asian British ‐ Bangladeshi Asian/Asian British ‐ other Asian Chinese Marital Status Marital Status Occurrences: 0…1 (optional) Coded Text: Widowed Divorced Separated Married (incl. civil partnership and common‐law) Partner Single ‐ supported Single – unsupported Education To record details of education level reached Details Occurrences: 0…1 (optional) Include: openEHR‐EHR‐CLUSTER.education_details.v1
Page 158 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
XII. Fitness and Lifestyle
ID eu.vph‐share.VPHOP.lifestyle.v1 Description A short object to capture basic details about a person's lifestyle, diet, etc. Keywords person, activity, fitness, diet Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.lifestyle.v3
Activity Level Occurrences: 0…1 (optional) Coded Text: Active Semi‐Active Sedentary Fitness Level Occurrences: 0…1 (optional) Coded Text: Fit Unfit Type of Occurrences: 0…1 (optional) Exercise Free or Coded Text Frequency Occurrences: 0…1 (optional) Quantity (Units: Number) /d /yr /wk Average Occurrences: 0…1 (optional) Duration Quantity (Units: Number) hours, months Diet Occurrences: 0…1 (optional) Coded Text: Normal Vegetarian Vegan Lactose free Gluten free Special Diet Details Occurrences: 0…1 (optional) Free or Coded Text Back Pain Records experience of back pain Occurrences: 0…1 (optional) Cardinality: 0…* (optional, repeating, unordered) Date of Date of last occurrence Occurrences: 0…1 (optional) Date: (Unit: yyyy‐mm‐dd) Severity Severity of back pain experienced Occurrences: 0…1 (optional)
Page 159 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Quantity (Unit: Ordinal) 0(no pain)…10(severe pain) Physical Physical abilities that may be performed by the individual Ability Occurrences: 0…1 (optional) Cardinality: 0…* (optional, repeating, unordered) Activity Type of activity performed Occurrences: 0…1 (optional) Coded Text: Reach a high shelf Lift a heavy object (10 kg) and carry it for 10 meters Wash and dry yourself all over Bend Forward Wash your hair over a basin Sit for one hour on a hard chair Stand continuously for 30 minutes Raise yourself in bed from a lying position Take socks on and off Bend down from a seated position Lift a box containing 6 litre bottles on a table Run 100 meters fast without stopping Tray of Plates Level of Level of exertion Exertion Occurences: 0…1 (optional) Include: openEHR‐EHR‐ CLUSTER.level_of_exertion.v1 Postural Postural Balance Balance Occurrences: 0…1 (optional) Quantity (Unit: Ordinal) 1…10 1 – unstable 10 – very stable
XIII. Employment Details
ID eu.vph‐share.VPHOP.employment_details.v1 Description To record the current and past employment details of a person Keywords substance, addiction, consumption, use, alcohol Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐CLUSTER.employment_details.v5
Current Identification of substance employment Occurrences: 1…1 (mandatory) status Cardinality: 0…1 (optional) Coded Text: Employed
Page 160 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Employed part time Unemployed Retired Volunteer Carer Student Sick or disabled permanently Sick or disabled temporarily Current Current Occupation of the person Occupation Occurrences: 0…1 (optional) Cardinality: 0…1 (optional, non‐repeating) Free or Coded Text Date of Occurrences: 0…1 (optional) Employment Date/Time Role/Job Occurrences: 0…* (optional, repeating) Free or Coded Text Occupation Occurrences: 0…1 (optional) Free or Coded text Occupational Overview of occupational health and safety risk Health & Occurrences: 0…1 (optional) Safety Risk Cardinality: 0…* (optional, repeating, unordered) Identified Occurrences: 0…1 (optional) Risk Free or Coded Text Exposure Occurrences: 0…1 (optional) Details Free or Coded Text
XIV. Vital Signs A. Heart Rate
ID eu.vph‐share.VPHOP.heart_rate.v1 Description The rate the heart is beating ‐ either mechanically or electrically Keywords heart rate, vital signs Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.heart_rate.v3
Rate The rate of the heart as beats per minute Occurrences: 0…1 (optional) Quantity (Units: Number) /min limit decimal places = 0 Rhythm The rhythm of the heart beat Occurrences: 0…1 (optional) Coded Text: Regular Irregular Irregularly irregular Description The description of the rate and rhythm
Page 161 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Occurrences: 0…1 (optional) Free or Coded Text Position The position of the patient when the heart rate was measured Occurrences: 0…1 (optional) Coded Text: Lying Sitting Reclining Standing Device Device by which the heart rate was measured Occurrences: 0…1 (optional) Free Text
B. Blood Pressure
ID eu.vph‐share.VPHOP.blood_pressure.v1 Description The measurement by any means (invasive or non‐invasive) of systemic arterial blood pressure which is deemed to represent the actual systemic blood pressure Keywords Blood, blood pressure, vital signs Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.blood_pressure.v5
Systolic Peak systemic arterial blood pressure over one cycle ‐ measured in systolic or contraction phase of the heart cycle [SNOMED‐CT: 163030003] Occurrences: 1…1 (mandatory) Quantity (Units: mm[Hg]) 0…<1000 Diastolic Minimum systemic arterial blood pressure over one cycle ‐ measured in the diastolic or relaxation phase [SNOMED‐CT: 163031004] Occurrences: 1…1 (mandatory) Quantity (Units: mm[Hg]) 0…<1000 Mean Arterial The average arterial pressure that occurs over the entire Pressure course of the heart contraction and relaxation cycle ‐ calculated by (2XSBP + DBP) divided by 3. Occurrences: 0…1 (optional) Quantity (Units: mm[Hg]) 0…<750 Limit decimal places = 1 Pulse Pressure The variation in pressure over one contraction cycle Occurrences: 0…1 (optional) Quantity (Units: mm[Hg]) 0…<750 Limit decimal places = 1 Ankle Brachial A measure of the reduction in arterial blood pressure of the Pressure legs used to detect evidence of blockages (peripheral Index vascular disease). It is calculated by dividing the highest systolic blood pressure in the arteries at the ankle and foot
Page 162 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
by the higher of the two systolic blood pressures in the arms. Occurrences: 0…1 (optional) Quantity (Units: Number) >=0 limit decimal places = 1 State The position and exertion level at which the reading was taken. Occurrences: 0…1 (optional) Cardinality: 0…1 (optional) Position The position of the patient at the time of measuring blood pressure Occurrences: 1…1 (mandatory) Coded Text: Standing Sitting Reclining Lying Exertion The level of exertion at the time of taking Level the measurement Occurrences: 0…1 (optional) Quantity (Unit: J/min) 0…1000 Exercise The classification of the exercise level Occurrences: 0…1 (optional) Coded Text: At rest Post‐exercise During exercise Tilt The tilt of the surface on which the person is lying Occurrences: 0…1 (optional) Quantity (Unit: Angle) ‐90…90 History Historical readings taken at 5 and 10 minute intervals Occurrences: 0…1 (optional) Cardinality: 0…1 (optional) Baseline Baseline event in event history Occurrences: 0…1 (optional) PointInTime 5 minute Blood pressure reading after 5 minutes rest reading Occurrences: 0…1 (optional) PointInTime 10 minute Blood pressure reading after 10 minutes reading rest Occurrences: 0…1 (optional) PointInTime Postural The difference between standing and Change sitting/lying blood pressure Occurrences: 0…* (optional) PointInTime
Page 163 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Paradox Variation in blood pressure with respiration Occurrences: 0…* (optional) PointInTime Cuff Size The size of the cuff if a sphygmomanometer is used [SNOMED‐CT: 246153002] Occurrences: 0…1 (optional) Coded Text: Adult Large Adult Paediatric/Child Adult Thigh Neonatal Infant Small Adult Instrument The instrument used to measure the blood pressure [SNOMED‐CT: 57134006] Occurrences: 0…1 (optional) Free or Coded Text Location of The site of the measurement of the blood pressure measurement Occurrences: 0…1 (optional) Coded Text: Right arm Left arm Right leg Left leg Intra‐arterial Right wrist Left wrist Korotkoff Record which Korotkoff sound is used for determining sounds Diastolic pressure Coded Text: Fourth sound Fifth sound Comment Comment on blood pressure reading Occurrences: 0…1 (optional) Free or Coded Text
C. Respiration
ID eu.vph‐share.VPHOP.repiration.v1 Description The rate and character of breathing Keywords Respiration, vital signs Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.respiration.v7
Rate The rate of respirations
Page 164 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Occurrences: 1…1 (mandatory) Quantity (Units: Number) /min >=0 Rhythm The rhythm of the respiration Occurrences: 0…1 (optional) Coded Text: Regular Irregular Cheyne‐Stokes Apnoeic episodes Character The character of the respirations Occurrences: 0…1 (optional) Coded Text: Gasping Grunting Kussmaul Snoring Inspiratory stridor Paradoxical breathing Recessing Nasal flare Apnoea Breathlessness Cough Excessive Secretions Wheeze None Depth Depth of respiration Occurrences: 0…1 (optional) Coded Text: Shallow Normal Deep FiO2 Fraction of inspired oxygen Occurrences: 0…1 (optional) Quantity (Unit: Percentage) % 0…100 Comments Any comments about the respiration Occurrences: 0…1 (optional) Free Text
D. Body Temperature
ID eu.vph‐share.VPHOP.body_temperature.v1 Description An estimate of the core temperature of the body Keywords body temperature, vital signs Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐OBSERVATION.body_temperature.v5
Page 165 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Temperature The core body temperature Occurrences: 1…1 (mandatory) Quantity (Units: Degree) °C °F Thermal The thermal situation of the person who is having the Situation temperature taken Occurrences: 0…1 (optional) Coded Text: Indoor ‐ normal clothing or bedding Indoor ‐ reduced clothing or bedding Indoor ‐ increased clothing or bedding Outdoors ‐ normal clothing Outdoors ‐ reduced clothing Outdoors ‐ increased clothing Thermal stress ‐ downward Thermal stress ‐ upward Paediatric incubator Naked Ambient The temperature to which the person has been exposed Temperature Occurrences: 0…1 (optional) Quantity (Units: Degree) °C °F Description of Description of the conditions applied to the patient to Thermal change temperature Stress Occurrences: 0…1 (optional) Free or Coded Text Site of The site of measurement of the temperature Measurement Occurrences: 0…1 (optional) Coded Text: Oral Aural Axilla Rectal Core Urinary bladder Intravascular Temporal
XV. Substance Use A. Alcohol
ID eu.vph‐share.VPHOP.substance_use_summary‐alcohol.v1 Description Archetype to record a persisting summary or overview of use or consumption of alcohol at the present time, a specific time or over a period of time. Keywords substance, addiction, consumption, use, alcohol Occurrences 0…1 (optional) Cardinality 0…1 (optional)
Page 166 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
References openEHR‐EHR‐EVALUATION.substance‐alcohol.v1
Substance Identification of substance Occurrences: 1…1 (mandatory) Coded Text: Alcohol Usage Status Overview of usage of alcohol Occurrences: 1…1 (mandatory) Coded Text: Current User Former Regular User Former Occasional User Never Used Form Form of the alcohol used Occurrences: 0…1 (optional) Coded Text: All alcohol All beer All wine All spirits Full strength beer Light beer Red wine White wine Fortified wine Date Date when use commenced Commenced Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??) Date ceased Date when used ceased Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??) Standard Frequency of standard drinks of alcohol consumed Drinks Occurrences: 1…1 (mandatory) Quantity (Units: Unit) unit/h unit/d unit/wk Comment Other information of substance use Occurrences: 0…1 (optional) Free or Coded Text B. Tobacco
ID eu.vph‐share.VPHOP.substance_use_summary‐tobacco.v1 Description Archetype to record a persisting summary or overview of use or consumption of tobacco at the present time, a specific time or over a period of time. Keywords substance, addiction, consumption, use, tobacco Occurrences 0…1 (optional)
Page 167 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Cardinality 0…1 (optional) References openEHR‐EHR‐EVALUATION.substance‐tobacco.v1
Substance Identification of substance Occurrences: 1…1 (mandatory) Coded Text: Tobacco Usage Status Overview of usage of alcohol Occurrences: 1…1 (mandatory) Coded Text: Current User Former Regular User Former Occasional User Never Used Form Form of the alcohol used Occurrences: 0…1 (optional) Coded Text: Cigarettes ‐ manufactured Cigarettes ‐ roll‐your‐own Cigars Pipe Date Date when use commenced Commenced Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??) Date ceased Date when used ceased Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??) Number Frequency of units containing tobacco consumed e.g. Smoked cigarettes or cigars Occurrences: 1…1 (mandatory) Quantity (Units: Unit) unit/h unit/d unit/wk Comment Other information of substance use Occurrences: 0…1 (optional) Free or Coded Text
C. Calcium
ID eu.vph‐share.VPHOP.substance_use_summary‐calcium.v1 Description Archetype to record a persisting summary or overview of use or consumption of calcium at the present time, a specific time or over a period of time. Keywords substance, addiction, consumption, use, calcium Occurrences 0…1 (optional) Cardinality 0…1 (optional)
Page 168 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
References openEHR‐EHR‐EVALUATION.substance‐calcium.v1
Substance Identification of substance Occurrences: 1…1 (mandatory) Coded Text: Calcium Usage Status Overview of usage of calcium Occurrences: 1…1 (mandatory) Coded Text: Current User Former Regular User Former Occasional User Never Used Form Form of the alcohol used Occurrences: 0…1 (optional) Free Text or Choice: Hard Cheese Soft Cheese Yoghurt Milk Date Date when use commenced Commenced Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??) Date ceased Date when used ceased Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??) Amount Frequency consumed ‐ only one quantity is permitted Consumed Occurrences: 0…1 (optional) Cardinality: 0…1 (optional) Cups of Consumption of coffee or tea coffee or tea Occurrences: 0…* (optional, repeating) Quantity (Units: Cups) cups/d cups/wk Shots of Consumption of espresso coffee by shots espresso Occurrences: 0…1 (optional) coffee Quantity (Units: Number) >=0 Volume of Consumption of caffeine‐containing soft soft drink drink by volume Occurrences: 0..* (optional, repeating) Quantity (Units: Millilitre) ml/d ml/wk Comment Other information of substance use Occurrences: 0…1 (optional) Free or Coded Text
Page 169 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
D. Caffeine
ID eu.vph‐share.VPHOP.substance_use_summary‐caffeine.v1 Description Archetype to record a persisting summary or overview of use or consumption of caffeine at the present time, a specific time or over a period of time. Keywords substance, addiction, consumption, use, caffeine Occurrences 0…1 (optional) Cardinality 0…1 (optional) References openEHR‐EHR‐EVALUATION.substance‐caffeine.v1
Substance Identification of substance Occurrences: 1…1 (mandatory) Coded Text: Caffeine Usage Status Overview of usage of caffiene Occurrences: 1…1 (mandatory) Coded Text: Current User Former Regular User Former Occasional User Never Used Form Form of the alcohol used Occurrences: 0…1 (optional) Coded Text: Coffee ‐ instant Coffee ‐ brewed/filtered Coffee ‐ espresso Tea Soft drink Date Date when use commenced Commenced Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??) Date ceased Date when used ceased Occurrences: 0…1 (optional) Date: (Unit: yyyy‐??‐??) Amount Frequency consumed ‐ only one quantity is permitted Consumed Occurrences: 0…1 (optional) Cardinality: 0…1 (optional) Cups of Consumption of coffee or tea coffee or tea Occurrences: 0…* (optional, repeating) Quantity (Units: Cups) cups/d cups/wk Shots of Consumption of espresso coffee by shots espresso Occurrences: 0…1 (optional) coffee Quantity (Units: Number) >=0 Volume of Consumption of caffeine‐containing soft
Page 170 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
soft drink drink by volume Occurrences: 0..* (optional, repeating) Quantity (Units: Millilitre) ml/d ml/wk Comment Other information of substance use Occurrences: 0…1 (optional) Free or Coded Text
XVI. Medication History ID eu.vph‐share.VPHOP.medications.v1 Description For recording questions and answers about medication use. Keywords medication, history Occurrences 0…1 (optional) Cardinality 0…* (optional, repeating, unordered) References openEHR‐EHR‐EVALUATION.check_list‐medication.v3
Medication Name of medication used or previously taken Occurrences: 1…1 (mandatory) Free Text or Choice: Androgen Calcitonin Calcium Flouride Vitamin D Alendronate Risendronate Other biphosphate Raloxifene PTH Ibandronate Zoledronate Tibolone Strontium Ranelate Cortocosteroids Inhaled Corticosteroids Inhaled Sulbutamol (ventolin) Oral Contraceptives Female Sex Hormones Medication ID SNOMED‐CT ID of the Medication Prescribed Occurrences: 1…1 (mandatory) Coded Text Dose Amount of drug prescribed to be taken daily Occurrences: 1…1 (mandatory) Quantity (Units: mg) /d Date Last Date the medication was last taken Used Occurrences: 0…1 (optional)
Page 171 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
XVII. Gynaecological Information ID eu.vph‐share.VPHOP.gynecological_information.v1 Description For recording questions and answers about gynaecological information (women). Keywords medication, history Occurrences 0…1 (optional) Cardinality 0…* (optional, repeating, unordered) References openEHR‐EHR‐EVALUATION.check_list‐medication.v3
Menstruation Information about menstruation cycle Occurrence: 0…1 (optional) Cardinality: 1…1 (mandatory) Date of first Date of first occurrence occurrence Occurrence: 0..1 (optional) Quantity (Unit: Date) yyy‐mm‐dd Date of Last Date of last occurrence Occurrence Occurrence: 0..1 (optional) Quantity (Unit: Date) yyy‐mm‐dd Duration Duration of Mensturation Occurrences: 0…1 (optional) Quantity (Unit: Time) >=0.0 /d /wk Current Day Number of days since onset of last normal of Cycle menstrual period Occurrences: 0…1 (optional) Quantity (Unit: Number) >=1 Menopause Occurrence of Symptoms around menopause Symptoms Occurrences: 0…1 (optional) Free Text of Choice: Flushing Depression Sleep Disturbance Pregnancies An overview of the obstetric history of a woman, including a summary of all pregnancies and the associated outcomes or interventions. Occurrences: 0…1 (optional) Include: openEHR‐EHR‐EVALUATION.obstetric_summary.v1
XVIII. Orthopaedic Health Event
ID eu.vph‐share. VPHOP. orthopaedic_health_event.v1 Description A diagnosis defined by a clinician that is coded in an accepted terminology and may include the stage of the condition and the diagnostic criteria. Keywords Occurrences 0…1 (optional) Cardinality 0…* (optional, repeating, unordered)
Page 172 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
References openEHR‐EHR‐EVALUATION.problem‐diagnosis.v1
Diagnosis The index Diagnosis Occurrences: 1…1 (mandatory) Free Text or Choice: Hyperthyroidism Diabetes Osteoporosis Vertebral Fractures Hip Fractures Rib Fractures Forearm Fractures Hand Fractures Thigh Fractures Ankle Fractures Foot Fractures Other Fractures in the arm Other Fractures in the leg Fall Musculoskeletal Pain State The status of the diagnosis Occurrences: 1…1 (mandatory) Coded Text: Confirmed Provisional Working Clinical Description of the clinical aspects of the problem Description Occurrences: 0…1 (optional) Free or Coded Text Severity The severity index of the problem Occurrences: 0…1 (optional) Ordinal 1. Mild 4. Moderate 7. Severe Date of last The date of first occurrence or exacerbation occurrence Occurrences: 0…1 (optional) Date/Time Date of first The date of last occurrence or exacerbation occurrence Occurrences: 0…1 (optional) Date/Time Anatomical The anatomical site(s) to be imaged Location Occurrences: 0…* (optional, repeating) Include: openEHR‐EHR‐CLUSTER.physical_properties.v1 and specialisations Family History Risk of condition based on family history Occurrences: 0…1 (optional)
Page 173 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Include: openEHR‐EHR‐EVALUATION.risk‐family_history.v1
XIX. Bone Phenotype Imaging Study
ID eu.vph‐share.VPHOP.imaging_study.v1 Description An bone phenotype classification action related to an investigation by an imaging technique. Keywords image, Xray, ultrasound, MRI, magnetic resonance, CT, scan, tomography Occurrences 1…1 (mandatory) Cardinality 1…* (mandatory, repeating, unordered) References openEHR‐EHR‐CLUSTER.imaging.v1
Clinical Clinical Findings relevant to the imaging investigations Findings Occurrences: 0…1 (optional) Free or Coded Text Imaging The Type of imaging Category Occurrences: 0…1 (optional) Coded Text: DXA Imaging Test Imaging test requested or performed Name Occurrences: 0…1 (optional) Free or Coded Text Study The study identifier the imaging procedure is related to Identifier Occurrences: 0…1 (optional) Identifier Anatomical The anatomical site(s) to be imaged Location Occurrences: 0…* (optional, repeating) Include: openEHR‐EHR‐CLUSTER.physical_properties.v1 and specialisations Reference Reference Population Population Occurrences: 0…1 (optional) Free or Coded Text Areal BMD at Areal BMD at Lumber Spine (L1‐L4) Lumber Spine Occurrences: 0…1 (optional) (L1‐L4) Free or Coded Text T‐Score at T‐Score at Lumbar Spine (L1‐L4) Lumbar Spine Occurrences: 0…1 (optional) (L1‐L4) Free or Coded Text Z‐Score at Z‐Score at Lumbar Spine (L1‐L4) Lumbar Spine Occurrences: 0…1 (optional) (L1‐L4) Free or Coded Text T‐Score at T‐Score at Proximal Femur Proximal Occurrences: 0…1 (optional) Femur Free or Coded Text Z‐Score at Z‐Score at Proximal Femur Proximal Occurrences: 0…1 (optional)
Page 174 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Femur Free or Coded Text Vertebral Presence of vertebral fractures at specific sites along the Fractures vertebra Occurrences: 0…1 (optional) Cardinality: 0…14 (optional, repeating, limited) ID Vertebra Identifier Occurrences: 1…1 (mandatory) Coded Text: T4 T5 T6 T7 T8 T9 T10 T11 T12 L1 L2 L3 L4 L5 Location Anatomical location identifier Occurrences: 0…1 (optional) Include: openEHR‐EHR‐ CLUSTER.physical_properties.v1 and specialisations Genant Genant Classification Classification Occurrences: 1…1 (mandatory) Coded Text Bone Bone Turnover Turnover Occurrences: 0…1 (optional) Cardinality: 0…1 (optional) P1NP P1NP Occurrences: 0…1 (optional) Free or Coded Text CTX CTX Occurrences: 0…1 (optional) Free or Coded Text 25OH vit D 25OH vit D Occurrences: 0…1 (optional) Free or Coded Text PTH PTH Occurrences: 0…1 (optional) Free or Coded Text Creatinine Creatinine Occurrences: 0…1 (optional)
Page 175 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Free or Coded Text Whole Body Whole Body Composition Composition BMD BMD Occurrences: 0…1 (optional) Free or Coded Text T‐Score T‐Score Occurrences: 0…1 (optional) Free or Coded Text Z‐Score Z‐Score Occurrences: 0…1 (optional) Free or Coded Text BMC BMC Occurrences: 0…1 (optional) Free or Coded Text Total Fat Total Fat Mass Mass Occurrences: 0…1 (optional) Free or Coded Text Total Lean Total Lean Mass Mass Occurrences: 0…1 (optional) Free or Coded Text View Details about a particular view Occurrences: 0…* (optional, repeating) Cardinality: 1…* (mandatory, repeating, unordered) View Name A description of the view taken Occurrences: 0…1 (optional) Per View Findings related to the view taken Findings Occurrences: 0…1 (optional) Image Unique identifier of the image, normally Identifier assigned by the healthcare organisation or device. Occurrences: 1…1 (mandatory) Identifier Image Link to Multimedia Image Occurrences: 1…1 (mandatory) URI Overall Summary of imaging findings Findings Occurrences: 0…1 (optional) Free or Coded Text Imaging Information regarding the quality of the imaging that may Quality influence reporting Occurrences: 0…1 (optional) Free or Coded Text Date of The date of the imaging is to be or was carried out Imaging Occurrences: 0…1 (optional) Date/Time
Page 176 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Location Occurrences: 0…1 (optional) Free or Coded Text
XX. Imaging Details
ID eu.vph‐share.VPHOP.imaging_details.v1 Description Details of imaging, used in requests for imaging, records of imaging procedures and imaging reports. Keywords image, mri, x‐ray, Occurrences 1…1 (mandatory) Cardinality 1…* (mandatory, repeating, unordered) References openEHR‐EHR‐CLUSTER.imaging.v1
Imaging The Type of imaging Category Occurrences: 0…1 (optional) Free or Coded Text Imaging Test Imaging test requested or performed Name Occurrences: 0…1 (optional) Free or Coded Text Study Identifier for the related study Identifier Occurrences: 0…1 (optional) Identifier Anatomical The anatomical site(s) to be imaged Location Occurrences: 0…* (optional, repeating) Include: openEHR‐EHR‐CLUSTER.physical_properties.v1 and specialisations View Details about a particular view Occurrences: 0…* (optional, repeating) Cardinality: 1…* (mandatory, repeating, unordered) View Name A description of the view taken Occurrences: 0…1 (optional) Per View Findings related to the view taken Findings Occurrences: 0…1 (optional) Image Unique identifier of the image, normally Identifier assigned by the healthcare organisation or device. Occurrences: 1…1 (mandatory) Identifier Image Link to Multimedia Image Occurrences: 1…1 (mandatory) URI Overall Summary of imaging findings Findings Occurrences: 0…1 (optional) Free or Coded Text Imaging Information regarding the quality of the imaging that may Quality influence reporting
Page 177 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Occurrences: 0…1 (optional) Free or Coded Text
XXI. Hand Grip Strength
ID eu.vph‐share.VPHOP.hand_grip_strength.v1 Description A recoding of hand grip strength. Keywords Occurrences 0…1 (optional) Cardinality 0…* (optional, repeating, unordered) References
Left Hand Grip Measurements about the left hand grip strength Occurrences: 0…1 (optional) Cardinality: 1…* (mandatory, repeating, unordered) Quantity (Units: kg) Right Hand Measurements about the right hand grip strength Grip Occurrences: 0…1 (optional) Cardinality: 1…* (mandatory, repeating, unordered) Quantity (Units: kg) Left Hand Mean Measurements about the left hand grip strength Mean Occurrences: 1…1 (mandatory) Measurement Cardinality: 1…1 (mandatory, repeating, unordered) Quantity (Units: kg) Right Hand Mean Measurements about the right hand grip strength Mean Occurrences: 1…1 (mandatory) Measurement Cardinality: 1…1 (mandatory, repeating, unordered) Quantity (Units: kg)
XXII. Supporting Risk Factors
ID eu.vph‐[email protected]_risk_factors.v1 Description A diagnosis defined by a clinician which is coded in an accepted terminology and may include the stage of the condition and the diagnostic criteria. Keywords Occurrences 0…1 (optional) Cardinality 0…* (optional, repeating, unordered) References openEHR‐EHR‐EVALUATION.problem‐diagnosis.v1
Diagnosis The index Diagnosis Occurrences: 1…1 (mandatory) Free Text or Choice: Assistive Devices Constant Wearing Glasses Cataract State The status of the diagnosis
Page 178 of 179 FP7 – ICT – 269978, VPH-Share WP5: Patient-Centred Multiscale Computational Workflows D5.1: Patient Avatar Defined for Flagship Workflows Version: 1.2 Date: 30-Nov-11
Occurrences: 1…1 (mandatory) Coded Text: Confirmed Provisional Working Clinical Description of the clinical aspects of the problem Description Occurrences: 0…1 (optional) Free or Coded Text Severity The severity index of the problem Occurrences: 0…1 (optional) Ordinal 1. Mild 4. Moderate 7. Severe Date of last The date of last occurrence or exacerbation occurrence Occurrences: 0…1 (optional) Date/Time Family History Risk of condition based on family history Occurrences: 0…1 (optional) Include: openEHR‐EHR‐EVALUATION.risk‐family_history.v1
Page 179 of 179