archetype (adl_version=1.4; uid=c9cbb493-3a5e-4780-9fc5-9384c49ffcce) openEHR-EHR-COMPOSITION.problem_list.v2 concept [at0000] -- Problem list language original_language = <[ISO_639-1::en]> translations = < ["de"] = < language = <[ISO_639-1::de]> author = < ["name"] = <"Sarah Ballout"> ["organisation"] = <"MHH-Hanover"> ["email"] = <"ballout.sarah@mh-hannover.de"> > > ["ko"] = < language = <[ISO_639-1::ko]> author = < ["name"] = <"Seung-Jong Yu"> ["organisation"] = <"NOUSCO Co.,Ltd."> ["email"] = <"seungjong.yu@gmail.com"> > accreditation = <"Certified Board of Family Medicine in South Korea"> > ["pt-br"] = < language = <[ISO_639-1::pt-br]> author = < ["name"] = <"Vladimir Pizzo"> ["organisation"] = <"Hospital Sirio Libanes, Brazil"> ["email"] = <"vladimir.pizzo@hsl.org.br"> > > ["ar-sy"] = < language = <[ISO_639-1::ar-sy]> author = < ["name"] = <"Mona Saleh"> > > > description original_author = < ["name"] = <"Heather Leslie"> ["organisation"] = <"Atomica Informatics"> ["email"] = <"heather.leslie@atomicainformatics.com"> ["date"] = <"2013-02-19"> > details = < ["de"] = < language = <[ISO_639-1::de]> purpose = <"Zur Repräsentation einer beständigen und gepflegten Liste von festgestellten Diagnosen, Problemen der betroffenen Person oder bereits durchgeführten Verfahren, die sich auf die klinische Entscheidung und die Erbringung von Pflegeleistungen auswirken können."> use = <"Zur Repräsentation von einer geführten beständige Liste von festgestellten Diagnosen, Beschwerden des Patienten oder bereits durchgeführte Eingriffe oder auch positive Feststellungen bezüglich bekannter Ausschlussgründe oder fehlender Informationen über die Krankengeschichte zu erfassen. Die Liste kann auch als Quelle für aktuelle Anamnesedaten zum Austausch oder als Basis für die Entscheidungsunterstützung genutzt werden. Diese Liste kann aus drei Arten in Form von Anweisungen bestehen, die jeweils durch bestimmte Archetypen repräsentiert werden: - Aussagen über das Auftreten von Problemen, Diagnosen oder bisherigen Eingriffen werden mit den Archetypen EVALUATION.problem_diagnosis und/oder ACTION.procedure erfasst; oder - Aussagen über den konkreten Ausschluss von Problemen, Diagnosen oder bisherigen Eingriffen können z.B. mit den spezifischen Archetypen EVALUATION.exclusion-problem_diagnosis oder EVALUATION.exclusion-procedure erfasst werden: \"Keine signifikanten Probleme oder Diagnosen\" oder \"Keine Vorgeschichte relevanter Operationen oder Abläufe\"; oder - Aussagen über keine verfügbaren Informationen - weder ein konkretes Auftreten eines Problems, einer Diagnose oder eines durchgeführten Eingriffs noch eines konkreten Ausschlusses - können mit dem Archetyp EVALUATION.absence erfasst werden. Damit diese Liste korrekt und sicher als Grundlage für Entscheidungsunterstützungsaktivitäten und für den Austausch verwendet werden kann, sollte diese Problemliste idealerweise von einem für die Krankenakte verantwortlichen Arzt erstellt werden, anstatt vom klinischen System automatisch allein durch Geschäftsregeln verwaltet zu werden. In einem geschlossenen klinischen System wird erwartet, dass die Herkunft dieser Problemliste durch die Versionierung dieser COMPOSITION und ihres Inhalts verwaltet werden kann, mit der zusätzlichen Option eines systembezogenen Audit-Trails. Es ist zwar ideal eine Problemliste für jeden Pflegebedürftigen zu haben, aber es ist realistischer zu erwarten, dass es in einer dezentralen Umgebung mehrere Problemlisten für einen einzelnen Pflegebedürftigen zu geben, die jeweils für einen bestimmten Arzt, eine Behandlungsepisode oder in einem anderen Kontext verwaltet und priorisiert wird. So kann beispielsweise eine Problemliste für einen Hausarzt eine ganz andere Konfiguration sein als die, die für einen Fachchirurgen oder als Vorlage während einer stationären Krankenhausepisode dient. In der Primärversorgung ist es üblich, die Problemliste auf der Basis aktiver oder inaktiver Problemen oder Diagnosen zu organisieren; Fachärzte können es bevorzugen, ihre Liste nach Primärdiagnosen zu strukturieren, die sich auf ihre spezifische Fachrichtung beziehen, während sekundäre Diagnosen, die nicht auf ihre Fachrichtung bezogen sind; und eine stationäre Aufnahme kann zusätzliche Fragen im Zusammenhang mit unmittelbaren Pflegeschwerpunkten beinhalten, die nach der Entlassung nach Hause nicht relevant wären - für diese Zwecke gibt es einen Status-SLOT im Problem/Diagnose-Archetyp, der die Verwendung eines Archetyps ermöglicht, der klinische Systeme unterstützen könnte, um Problemlisten nach Maßgabe der Präferenz der klinischen Benutzer des Systems zu organisieren, ohne diese kontextuellen Statuskennzeichnungen für andere klinische Situationen oder zur Erhaltung fortzuführen. Dieser Archetyp wird in der Regel als beständige Liste verwaltet, es gibt jedoch Situationen, in denen die Liste innerhalb der Episodenversorgung verwendet werden kann und zusätzliche Attribute wie Kontext usw. benötigt, um eine genaue Aufzeichnung zu ermöglichen. Das openEHR-Referenzmodell erlaubt derzeit nur die Aufzeichnung von Kontexten innerhalb von ereignisbasierten COMPOSITION-Archetypen. Aus diesem Grund wurde dieser Archetyp als Event und nicht als COMPOSITION modelliert. Die Flexibilität ist somit gewährleistet, so dass einige klinische Systeme Problemlisten für Episoden der Pflege sicher verwalten können, während andere sich dafür entscheiden, diese COMPOSITION zu implementieren, um dauerhaft zu handeln. "> keywords = <"Problem", "Liste", "Diagnose", "Diagnosen", "Prozedur", "Problemliste", "Verfahren"> misuse = <""> > ["ko"] = < language = <[ISO_639-1::ko]> purpose = <"확인된 진단이나 환자가 겪는 문제 또는 임상의사결정과 환자진료에 영향을 줄 수 있는 이전에 시행된 처치에 대한 영구적으로 관리되는 목록."> use = <"확인된 진단이나 환자가 겪는 문제 또는 임상의사결정과 환자진료에 영향을 줄 수 있는 이전에 시행된 처치에 대한 영구적으로 관리되는 목록을 기록하는데 사용. 이 목록은 교환이나 의사결정을 위한 근거로써 최근의 문제목록 데이터로써 이용될 수 있다. 이 목록은 3가지의 아키타입 종류들로 구성된다. - 문제나 진단 또는 이전에 받은 처치가 있는(positive presence) 경우에 EVALUATION.problem_diagnosis 와/또는 ACTION.procedure 아키타입들을 이용하여 진술문이 기록된다; 또는 - 약물의 이용을 배제하는(positive exclusion) 진술문은 특별한 EVALUATION.exclusion-problem_diagnosis 또는 EVALUATION.exclusion-procedure 아키타입들을 이용하여 진술문이 기록될 수 있다 - 예를 들어, \"중요한 문제들이나 진단들이 없음\" 이나 \"중요한 수술들이나 처치들의 이력이 없음\"; 또는 - 이용가능한 정보가 없는 것(문제나 진단 또는 처치를 받거나 받지 않은 두 경우가 모두 아님)에 대한 진술문이 EVALUATION.absence 아키타입을 이용하여 기록될 수 있다. 이 목록이 의사결정과 교환의 근거로서 정확하고 안전하게 사용되기 위해서는 이 문제목록은 비즈니스 규칙들에 따라 임상시스템에 의해서 자동적으로 관리되기 보다는 이상적으로 기록에 책임이 있는 임상의에 의해 관리되어야 한다."> keywords = <"*문제(ko)", "*목록(ko)", "*진단(ko)", "*처치(ko)"> misuse = <""> copyright = <"© openEHR Foundation"> > ["pt-br"] = < language = <[ISO_639-1::pt-br]> purpose = <"Registrar uma lista permanente e gerenciável de diagnósticos identificados, problemas experimentados pelo indivíduo ou procedimentos previamente realizados, que podem influenciar o processo de tomada de decisão clínica e provisão do cuidado."> use = <"Utilizar como estrutura sugerida para apoiar modelagem consistente da Lista de problemas como uma lista de diagnósticos identificados, problemas vivenciados pelo indivíduo ou procedimentos previamente realizados persistente e gerenciável. Esta lista pode ser utilizada como uma fonte de dados da lista de problemas atuais para troca de informações ou base para suporte à decisão. Esta lista pode ser composta por três tipos de declarações, cada uma representada por arquétipos específicos: - declarações sobre a presença de problemas, diagnósticos ou procedimentos prévios são registradas utilizando arquétipos EVALUATION.problem_diagnosis e/ou ACTION.procedure archetypes; ou - declarações sobre a exclusão de problemas, diagnósticos ou procedimentos prévios podem ser registrados utilizando os arquétipos específicos EVALUATION.exclusion-problem_diagnosis ou EVALUATION.exclusion-procedure - por exemplo: \"Ausência de problemas ou diagnósticos significantes\" ou \"Ausência de história de procedimentos ou operações significantes\"; ou - declarações sobre a ausência de informações disponíveis - nem a afirmação da presença de um problema, diagnóstico ou procedimento realizado nem uma exclusão - pode ser registrado utilizando o arquétipo EVALUATION.absence. Para que esta lista seja acurada e segura para ser utilizada como base para atividades de suporte à decisão e troca de informações, esta Lista de Problemas deve, idealmente, estar sob a responsabilidade de um clínico para o registro de saúde ao invés de gerenciada automaticamente por um sistema clínico baseado apenas em regras de negócio. Num sistema clínico fechado, é esperado que a introdução da informação na Lista de prolemas seja gerenciada através do versionamento deste COMPOSITION e seu conteúdo com a opção de uma trilha de auditoria baseada no sistema. Embora o ideal seja ter apenas uma Lista de problemas para cada indivíduo é mais realista esperar que num ambiente compartilhado podem haver múltiplas listas para um sujeito do cuidado, cada uma gerenciada e priorizada por um médico, episódio de cuidado ou outro contexto específico. Por exemplo, uma Lista de problemas de um médico de atenção primária pode ter uma configuração bem diferente daquela que é útil para um cirurgião especialista ou para referência durante um episódio de internação hospitalar. Em atenção primária é comum organizar a Lista de problemas baseada em problemas ou diagnósticos ativos e inativos; especialistas podem preferir ver suas listas organizadas ao redor dos diagnósticos primários que estão relacionados às suas especialidades e secundariamente aqueles que não estão; e uma admissão hospitalar pode incluir aspectos adicionais relacionados a prioridades de enfermagem imediatas que podem não ser relevantes na alta domiciliar - para estes propósitos há um SLOT Status no arquétipo Problem/Diagnosis que permite o uso de um arquétipo que pode suportar sistemas clínicos para organizar as Listas de problemas de acordo com as preferências dos usuários clínicos dos sistemas, sem perpetuar estes rótulos de status contextuais para outros cenários clínicos. Este arquétipo é normalmente gerenciado como uma lista persistente, entretanto há situações em que a lista pode ser utilizada num contexto de cuidado episódico e requeira atributos adicionais como um contexto para permitir um registro acurado. Atualmente o modelo de referência openEHR apenas permite que o contexto seja registrado em arquétipos COMPOSITION baseados em Eventos. Como resultado este arquétipo vem sendo modelado como um Evento ao invés de Persistente, COMPOSITION para permitir a flexibilidade para que alguns sistemas clínicos possam gerenciar de maneira segura as Listas de problemas para episódios de cuidado, enquanto outros escolherão implementar este COMPOSITION para agir de maneira persistente."> keywords = <"lista", "problema", "diagnóstico", "procedimento", "lista de problemas"> misuse = <""> > ["ar-sy"] = < language = <[ISO_639-1::ar-sy]> purpose = <"للمحافظة على قائمة مُحكَمة للمشكلات الصحية الحالية المؤثرة التي يُعتَدّ بها للشخص."> use = <"للمشكلات النشطة و غير النشطة - و تُعرف المشكلات غير النشطة بوجود تاريخ البُرْء/الشفاء"> keywords = <"قائمة المشكلات", ...> misuse = <"لا يستخدم للمشكلات قصيرة المدى"> copyright = <"© openEHR Foundation"> > ["en"] = < language = <[ISO_639-1::en]> purpose = <"To record a persistent and managed list of diagnoses identified, problems experienced by the subject or previous procedures performed, that may influence clinical decision-making and care provision."> use = <"Use to record a persistent and managed list of diagnoses identified, problems experienced by the subject or previous procedures performed, or, alternatively, positive statements about known exclusions or actual absence of any information about the the medical history. This list can also be utilised as a source of up-to-date medical history data for exchange or as the basis for decision support. This list can be comprised of three types of statements, each represented by specific archetypes: - statements about the positive presence of problems, diagnoses or previous procedures are recorded using the EVALUATION.problem_diagnosis and/or ACTION.procedure archetypes; OR - statements about the positive exclusion of problems, diagnoses or previous procedures can be recorded using the specific EVALUATION.exclusion-problem_diagnosis or EVALUATION.exclusion-procedure archetypes - for example: \"No significant problems or diagnoses\" or \"No history of significant operations or procedures\"; OR - statements about no information being available - neither a positive presence of a problem, diagnosis or procedure performed nor a positive exclusion - can be recorded using the EVALUATION.absence archetype. In order for this list to be accurate and safe to use as the basis for decision support activities and for exchange, this Problem List should ideally be curated by a clinician responsible for the health record, rather than managed automatically by the clinical system through business rules alone. In a closed clinical system, it is expected that provenance of this Problem list can be managed through versioning of this COMPOSITION and its contents, with the additional option of a system-based audit trail. While it may be ideal to have only one Problem list for each subject of care, it is more realistic to expect that in a distributed environment there may be multiple Problem lists for a single subject of care, each managed and prioritised for a specific clinician, episode of care or other context. For example, a Problem list for a primary care clinician may be a very different configuration to that which is useful for a specialist surgeon or for reference during a hospital inpatient episode. In primary care it is common to organise the Problem list based on active or inactive problems or diagnoses; specialists may prefer to see their list organised around primary diagnoses which are related to their specific speciality and secondary ones which are not; and an inpatient admission may include additional issues related to immediate nursing priorities that would not be relevant once discharged home - for these purposes there is a Status SLOT in the Problem/Diagnosis archetype, which allow use of an archetype that could support clinical systems to organise Problem lists according to the preference of the clinical users of the system, without perpetuating these contextual status labels to other clinical scenarios or for persistence. This archetype is usually managed as a persistent list, however there are situations where the list may be used within episodic care and require additional attributes such as context etc to enable accurate recording. The openEHR reference model currently only allows context to be recorded within Event-based COMPOSITION archetypes. As a result, this archetype has been modelled as an Event, rather than Persistent, COMPOSITION, to allow for flexibility so that some clinical systems can safely manage Problem lists for episodes of care, while others will choose to implement this COMPOSITION to act in a persistent manner."> keywords = <"problem", "list", "diagnosis", "diagnoses", "procedure", "problem list"> misuse = <""> copyright = <"© openEHR Foundation"> > > lifecycle_state = <"published"> other_contributors = <"Nadim Anani, Karolinska Institutet, Sweden", "Vebjørn Arntzen, Oslo University Hospital, Norway", "Koray Atalag, University of Auckland, New Zealand", "Silje Ljosland Bakke, Nasjonal IKT HF, Norway (openEHR Editor)", "Sistine Barretto-Daniels, Ocean Informatics, Australia", "Lars Bitsch-Larsen, Haukeland University hospital, Norway", "Shahla Foozonkhah, Iran ministry of health and education, Iran", "Einar Fosse, National Centre for Integrated Care and Telemedicine, Norway", "Sebastian Garde, Ocean Informatics, Germany", "Heather Grain, Llewelyn Grain Informatics, Australia", "Sam Heard, Ocean Informatics, Australia", "Lars Karlsen, DIPS ASA, Norway", "Lars Morgan Karlsen, DIPS ASA, Norway", "Shinji Kobayashi, Kyoto University, Japan", "Heather Leslie, Atomica Informatics, Australia (openEHR Editor)", "Hallvard Lærum, Norwegian Directorate of e-health, Norway", "Ian McNicoll, freshEHR Clinical Informatics, United Kingdom (openEHR Editor)", "Andrej Orel, Marand d.o.o., Slovenia", "Jussara Rotzsch, Hospital Alemão Oswaldo Cruz, Brazil", "Rowan Thomas, St. Vincent's Hospital Melbourne, Australia", "John Tore Valand, Helse Bergen, Norway (openEHR Editor)"> other_details = < ["licence"] = <"This work is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/4.0/."> ["custodian_organisation"] = <"openEHR Foundation"> ["references"] = <"Problem List, draft archetype [Internet]. National eHealth Transition Authority, NEHTA Clinical Knowledge Manager. Authored: 2013 Feb 19. Available at: http://dcm.nehta.org.au/ckm/#showArchetype_1013.1.1235 [accessed 2015 Apr 28]."> ["current_contact"] = <"Heather Leslie, Atomica Informatics, heather.leslie@atomicainformatics.com"> ["original_namespace"] = <"org.openehr"> ["original_publisher"] = <"openEHR Foundation"> ["custodian_namespace"] = <"org.openehr"> ["MD5-CAM-1.0.1"] = <"46B8769828AF10041506B359B6A0D96B"> ["build_uid"] = <"7c289843-5d5a-4295-a823-f1561f15396a"> ["revision"] = <"2.0.0"> > definition COMPOSITION[at0000] matches { -- Problem list category matches { DV_CODED_TEXT matches { defining_code matches {[openehr::433]} } } context matches { EVENT_CONTEXT matches { other_context matches { ITEM_TREE[at0006] matches { -- Tree items cardinality matches {0..*; unordered} matches { allow_archetype CLUSTER[at0008] occurrences matches {0..*} matches { -- Extension include archetype_id/value matches {/.*/} } } } } } } } ontology term_definitions = < ["ar-sy"] = < items = < ["at0000"] = < text = <"قائمة المشكلات"> description = <"قائمة من المشكلات الصحية الحالية لهذا الشخص."> > ["at0006"] = < text = <"*Tree(en)"> description = <"*@ internal @(en)"> > ["at0008"] = < text = <"*Extension(en)"> description = <"*Additional information required to capture local context or to align with other reference models/formalisms.(en)"> comment = <"*For example: Local hospital departmental infomation or additional metadata to align with FHIR or CIMI equivalents.(en)"> > > > ["en"] = < items = < ["at0000"] = < text = <"Problem list"> description = <"A persistent and managed list of any combination of diagnoses, problems and/or procedures that may influence clinical decision-making and care provision for the subject of care."> > ["at0006"] = < text = <"Tree"> description = <"@ internal @"> > ["at0008"] = < text = <"Extension"> description = <"Additional information required to capture local context or to align with other reference models/formalisms."> comment = <"For example: Local hospital departmental infomation or additional metadata to align with FHIR or CIMI equivalents."> > > > ["ko"] = < items = < ["at0000"] = < text = <"문제 목록"> description = <"확인된 진단이나 환자가 겪는 문제 또는 임상의사결정과 환자진료에 영향을 줄 수 있는 이전에 시행된 처치에 대한 영구적으로 관리되는 목록."> > ["at0006"] = < text = <"*Tree(en)"> description = <"*@ internal @(en)"> > ["at0008"] = < text = <"*Extension(en)"> description = <"*Additional information required to capture local context or to align with other reference models/formalisms.(en)"> comment = <"*For example: Local hospital departmental infomation or additional metadata to align with FHIR or CIMI equivalents.(en)"> > > > ["pt-br"] = < items = < ["at0000"] = < text = <"Lista de problemas"> description = <"Uma lista permanente e gerenciável de quaisquer combinações de diagnósticos, problemas e/ou procedimentos que possam influenciar o processo de tomada de decisão clínica e provisão de cuidado ao indivíduo."> > ["at0006"] = < text = <"Tree"> description = <"@ internal @"> > ["at0008"] = < text = <"Extensão"> description = <"Informação adicional necessária para identificar contexto local ou alinhar com outros formalismos/modelos de referência."> comment = <"Por exemplo: informação departamental local de hospital ou metadados para alinhar com equivalentes FHIR ou CIMI."> > > > ["de"] = < items = < ["at0000"] = < text = <"Problemliste"> description = <"Eine beständige und gepflegte Liste jeder Kombination von Diagnosen, Problemen und/oder Verfahren, die sich auf die klinische Entscheidungsfindung und die Versorgung des Pflegebedürftigen auswirken können."> > ["at0006"] = < text = <"Tree"> description = <"@ internal @"> > ["at0008"] = < text = <"Erweiterung"> description = <"Zusätzliche Informationen die benötigt werden, um lokale Inhalte zu erfassen oder sich an andere Referenzmodelle/Formalismen an zupassen."> comment = <"Zum Beispiel: Lokaler Informationsbedarf zur internen Krankenhausabteilung oder zusätzliche Metadaten zum abstimmen mit FHIR oder CIMI Äquivalenten."> > > > >