Modelli di dati selezionati

Devi effettuare il log in per selezionare i modelli di dati da scaricare per successive analisi

6 Risultati di ricerca.
rilevanza Valutazione Più recente Meno recente

MS CDE Diagnosis and Disease Characteristics Multiple Sclerosis - Diagnosis and Disease Characteristics

- 20/06/18 - 1 modulo, 7 itemgroups, 61 elementi, 1 linguaggio
Itemgroups: Diagnosis; Disease Characteristics, Clinical Course MS, Clinical Course NMO, Clinical Course ADEM, Other Clinical Course, Diagnostic critera MS, Medical history disease onset
MS Common Data Elements, Multiple Sclerosis Diagnosis and Disease Characteristics for semantic analysis from the National Institute of Neurological Disorders and Stroke Common Data Elements (https://www.commondataelements.ninds.nih.gov/) References: Grinnon ST, Miller K, Marler JR, Lu Y, Stout A, Odenkirchen J, Kunitz S. National Institute of Neurological Disorders and Stroke Common Data Element Project - approach and methods. Clin Trials. 2012;9(3):322-9.

PCORnet Common Data Model (CDM) - Diagnosis V4.1

- 30/03/20 - 1 modulo, 1 ItemGroup, 17 elementi, 1 linguaggio
ItemGroup: Diagnosis
PCORnet Common Data Model (CDM) Diagnosis Diagnosis codes indicate the results of diagnostic processes and medical coding within healthcare delivery. Data in this table are expected to be from healthcare-mediated processes and reimbursement drivers. PCORnet Common Data Model (CDM) The PCORnet Common Data Model (CDM) is a specification that defines a standard organization and representationof data for the PCORnet Distributed Research Network. The PCORnet CDM is a key component of the PCORnet Distributed Research Network (DRN) infrastructure. http://www.pcornet.org/pcornet-common-data-model/

Sentinel Common Data Model Diagnosis

- 25/08/19 - 1 modulo, 1 ItemGroup, 10 elementi, 1 linguaggio
ItemGroup: Diagnosis
Sentinel: Overview and Description of the Common Data Model v7.0.0 "The primary goal of Sentinel is to build and operate a national public health surveillance system to monitor the safety of FDA-regulated medical products, including drugs, biologics, and devices. Sentinel is part of the Sentinel Initiative, the FDA’s response to a congressional mandate to create an active surveillance system using electronic health data.The Sentinel program will undertake three major types of activities: (1) prospective evaluation of accumulating experience about specific medical products and specific suspected safety problems; (2) evaluation of the impact of FDA actions (e.g., labeling changes) on medical practice and health outcomes; and (3) rapid assessment of past experience in response to FDA questions about specific exposures and outcomes." For more information about Sentinel visit the website at: www.sentinelsystem.org For comments and suggestions, please email: info@sentinelsystem.org Description: The SCDM Diagnosis Table contains one record per unique combination of PatID, EncounterID, DX, and DX_CodeType. This table should capture all uniquely recorded diagnoses for all encounters.

Problem/Diagnosis (EHR Archetype) - openEHR-EHR-EVALUATION.problem_diagnosis.v1

- 08/07/17 - 1 modulo, 1 ItemGroup, 18 elementi, 6 lingue
ItemGroup: openEHR-EHR-EVALUATION.problem_diagnosis.v1.xml
Derived from www.openehr.org . Use for recording details about a single, identified health problem or diagnosis. Clear definitions that enable differentiation between a 'problem' and a 'diagnosis' are almost impossible in practice - we cannot reliably tell when a problem should be regarded as a diagnosis. When diagnostic or classification criteria are successfully met, then we can confidently call the condition a formal diagnosis, but prior to these conditions being met and while there is supportive evidence available, it can also be valid to use the term 'diagnosis'. The amount of supportive evidence required for the label of diagnosis is not easy to define and in reality probably varies from condition to condition. Many standards committees have grappled with this definitional conundrum for years without clear resolution. For the purposes of clinical documentation with this archetype, problem and diagnosis are regarded as a continuum, with increasing levels of detail and supportive evidence usually providing weight towards the label of 'diagnosis'. In this archetype it is not neccessary to classify the condition as a 'problem' or 'diagnosis'. The data requirements to support documentation of either are identical, with additional data structure required to support inclusion of the evidence if and when it becomes available. Examples of problems include: the individual's expressed desire to lose weight, but without a formal diagnosis of Obesity; or a relationship problem with a family member. Examples of formal diagnoses would include a cancer that is supported by historical information, examination findings, histopathological findings, radiological findings and meets all requirements for known diagnostic criteria. In practice, most problems or diagnoses do not sit at either end of the problem-diagnosis spectrum, but somewhere in between. This archetype can be used within many contexts. For example, recording a problem or a clinical diagnosis during a clinical consultation; populating a persistent Problem List; or to provide a summary statement within a Discharge Summary document. In practice, clinicians use many context-specific qualifiers such as past/present, primary/secondary, active/inactive, admission/discharge etc. The contexts can be location-, specialisation-, episode- or workflow-specific, and these can cause confusion or even potential safety issues if perpetuated in Problem Lists or shared in documents that are outside of the original context. These qualifiers can be archetyped separately and included in the ‘Status’ slot, because their use varies in different settings. It is expected that these will be used mostly within the appropriate context and not shared out of that context without clear understanding of potential consequences. For example, a primary diagnosis to one clinician may be a secondary one to another specialist; an active problem can become inactive (or vice versa) and this can impact the safe use of clinical decision support. In general these qualifiers should be applied locally within the context of the clinical system, and in practice these statuses should be manually curated by clinicians to ensure that lists of Current/Past, Active/Inactive or Primary/Secondary Problems are clinically accurate. This archetype will be used as a component within the Problem Oriented Medical Record as described by Larry Weed. Additional archetypes, representing clinical concepts such as condition as an overarching organiser for diagnoses etc, will need to be developed to support this approach. In some situations, it may be assumed that identification of a diagnosis fits only within the expertise of physicians, but this is not the intent for this archetype. Diagnoses can be recorded using this archetype by any healthcare professional.

Ministry of Health, Ethiopia- Patient card - Patient card

- 11/07/16 - 1 modulo, 1 ItemGroup, 9 elementi, 1 linguaggio
ItemGroup: Patient card
Form provided by Binyam Tilahun. Source: http://www.moh.gov.et/ (Ministry of Health, Ethiopia)

ICD10 Chapters

- 25/08/15 - 1 modulo, 1 ItemGroup, 1 elemento, 2 lingue
ItemGroup: ICD10 Chapters
ODM derived from http://www.who.int/classifications/icd/en/ https://www.dimdi.de/static/de/klassi/icd-10-who/

Contatto

Si prega di utilizzare questo modulo per feedback, domande e suggerimenti per miglioramenti.

I campi contrassegnati da * sono obbligatori.

Aiuto

Do you need help on how to use the search function? Please watch the corresponding tutorial video for more details and learn how to use the search function most efficiently.

Watch Tutorial