<commit_before><?xml version="1.0" encoding="UTF-8"?>
<article version="5.0" xml:lang="en-US" xmlns="http://docbook.org/ns/docbook"
         xmlns:xlink="http://www.w3.org/1999/xlink"
         xmlns:ns5="http://www.w3.org/1999/xhtml"
         xmlns:ns4="http://www.w3.org/1998/Math/MathML"
         xmlns:ns3="http://www.w3.org/2000/svg"
         xmlns:ns="http://docbook.org/ns/docbook">
  <info>
    <title>Clinical Observation Modeling for Electronic Health Records:
    Supporting Domain Semantics, Flexibility, and Interoperability</title>

    <author>
      <personname><NAME></personname>
    </author>

    <date>2017-02-14</date>
  </info>

  <section>
    <title>Introduction</title>

    <para>This white paper emerged from discussions among informaticists,
    computer scientists, and medical doctors about the appropriate modeling of
    clinical observations in information systems. The participants included
    representatives of the VHA-DoD, CIMI, HL7-FHIR, FHIM, SNOMED-CT, and
    OpenEHR initiatives<footnote xml:id="__FN1__">
        <para>VHA = Veterans Health Administration; CIMI = Clinical
        Information Modeling Initiative; HL7-FHIR = HL7 Fast Healthcare
        Interoperability Resources working group; FHIM = Federal Health
        Information Modeling.</para>
      </footnote>. The paper does not necessarily represent a consensus among
    the discussants or the viewpoint of any particular discussant. Its purpose
    is to provide background on the topic, to summarize a number of the
    viewpoints expressed, and to provide preliminary recommendations for
    further consideration. The contents are subject to further modification as
    the discussion evolves.</para>
  </section>

  <section>
    <title>Clinical Observation Models</title>

    <para>Clinical observation models (COMs<footnote xml:id="__FN2__">
        <para>Clinical Observation Models are also referred to as
        “Archetypes,” “Clinical Event Models,” and “Clinical Models” in the
        informatics literature and vernacular.</para>
      </footnote>) are conceptual-level data models of the discrete statements
    about patients that can be stored in, processed by, and retrieved from a
    clinical information system. COMs are defined for discrete types of
    clinical statements such as blood pressure measurements, lab test results,
    physical exam findings, patient-reported symptoms, clinical diagnoses, and
    other observations.</para>

    <para>COMs define the structure and semantics of discrete clinical
    observations as formal “types” that are later instantiated to represent
    specific recorded observations that apply to particular patients. Like
    object types in programming languages, these type definitions include
    enumerations of the specific data elements that may make up the
    observation, the datatypes used to populate those elements, and which
    elements must be populated in every instantiated object versus optionally
    populated. <xref linkend="_Ref474327938"/> shows the graphical depiction
    of an example COM for a blood pressure measurement.</para>

    <figure xml:id="_Ref474327938"><commit_msg>Changed name of main file<commit_after><?xml version="1.0" encoding="UTF-8"?>
<article version="5.0" xml:lang="en-US" xmlns="http://docbook.org/ns/docbook"
         xmlns:xlink="http://www.w3.org/1999/xlink"
         xmlns:ns5="http://www.w3.org/1999/xhtml"
         xmlns:ns4="http://www.w3.org/1998/Math/MathML"
         xmlns:ns3="http://www.w3.org/2000/svg"
         xmlns:ns="http://docbook.org/ns/docbook">
  <info>
    <title>Clinical Observation Modeling for Electronic Health Records:
    Supporting Domain Semantics, Flexibility, and Interoperability</title>

    <author>
      <personname><NAME></personname>
    </author>

    <date>2017-02-14</date>
  </info>

  <section>
    <title>Introduction</title>

    <para>This white paper emerged from discussions among informaticists,
    computer scientists, and medical doctors about the appropriate modeling of
    clinical observations in information systems. The participants included
    representatives of the VHA-DoD, CIMI, HL7-FHIR, FHIM, SNOMED-CT, and
    OpenEHR initiatives<footnote xml:id="__FN1__">
        <para>VHA = Veterans Health Administration; CIMI = Clinical
        Information Modeling Initiative; HL7-FHIR = HL7 Fast Healthcare
        Interoperability Resources working group; FHIM = Federal Health
        Information Modeling.</para>
      </footnote>. The paper does not necessarily represent a consensus among
    the discussants or the viewpoint of any particular discussant. Its purpose
    is to provide background on the topic, to summarize a number of the
    viewpoints expressed, and to provide preliminary recommendations for
    further consideration. The contents are subject to further modification as
    the discussion evolves.</para>
  </section>

  <section>
    <title>Clinical Observation Models</title>

    <para>Clinical observation models (COMs<footnote xml:id="__FN2__">
        <para>Clinical Observation Models are also referred to as “Archetypes,” “Clinical Event
          Models,” and “Clinical Models” in the informatics literature and vernacular.</para>
      </footnote>) are conceptual-level data models of the discrete statements about patients that
      can be stored in, processed by, and retrieved from a clinical information system. COMs are
      defined for discrete types of clinical statements such as blood pressure measurements, lab
      test results, physical exam findings, patient-reported symptoms, clinical diagnoses, and other
      observations.</para>

    <para>COMs define the structure and semantics of discrete clinical
    observations as formal “types” that are later instantiated to represent
    specific recorded observations that apply to particular patients. Like
    object types in programming languages, these type definitions include
    enumerations of the specific data elements that may make up the
    observation, the datatypes used to populate those elements, and which
    elements must be populated in every instantiated object versus optionally
    populated. <xref linkend="_Ref474327938"/> shows the graphical depiction
    of an example COM for a blood pressure measurement.</para>

    <figure xml:id="_Ref474327938">
{'fraction_non_alphanumeric': 0.0785669390320553, 'fraction_numerical': 0.018541797611565054, 'mean_word_length': 3.7821187077385425, 'pattern_counts': {'":': 0, '<': 75, '<?xml version=': 2, '>': 75, 'https://': 0, 'lorem ipsum': 0, 'www.': 8, 'xml': 22}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5101383', 'n_tokens_mistral': 1754, 'n_tokens_neox': 1597, 'n_words': 637}