CRM Taskforce Meeting Minutes - 12 April 2012

From CIMI
Jump to: navigation, search

Attendees

  • Linda Bird (Ministry of Health Holdings, Singapore)
  • Gerard Freriks (EN13606 Association)
  • Richard Kavanagh (NHS Connecting for Health)
  • Thomas Beale (Ocean Informatics)
  • Stan Huff (Intermountain Healthcare) [First 30 mins]
  • Cecil Lynch (Accenture) - CIMI Clinical Modelling Taskforce [First 30 mins]
  • Ian Townend (NHS Connecting for Health) -- Guest

Apologies

  • Josh Mandel (SMArt)
  • Michael van der Zel (Results4Care)
  • Galen Mulrooney, ONC, U.S.A.
  • Grahame Grieve (Health Intersections)

Agenda

  • Update from IEC
  • Update from Clinical Modelling taskforce (interim tooling, clinical patterns)
  • Update on tooling (e.g. Requirements, ADL WB schedule, XMI imports)
  • Update on datatypes work
  • Semantic links
  • Core reference model - other requirements gaps to consider?
  • Plan / Actions

Brief Summary

  • Update from IEC
    • Seeing how to align with standards bodies or other an organisation
    • To own the IP CIMI needs to become a business entity or align with another business entity (the preference)
    • Writing an RFI to define CIMI’s principles (including IP, governance)
  • Update from Clinical Modelling taskforce (interim tooling, clinical patterns)
    • Example clinical models using OWL-based (interim) notation
    • Clinical Patterns Discussion
      • openEHR Entry specialisations (e.g. Observation, Evaluation, Instruction, Action) to be tested using clinical model examples
      • Support was expressed for these clinical patterns to be represented as a first-level archetype, upon which other specific clinical models are based. The advantages of this approach are:
        • Keeps the reference model small and simple
        • Allows flexible feedback and evaluation of new ideas within archetype editing environment (rather than a reference model editing environment)
        • Allows for consistent approach to constraining all clinical semantics
      • The disadvantages of this approach are:
        • Instance data are less readable
        • Clinical patterns may not be able to be hard wired into software as easily.
  • Update on tooling (e.g. Requirements, ADL WB schedule, XMI imports)
    • Requirements (as defined last week) are being worked on
    • Importing XMI from BOUML into Enterprise Architect may have issues with preserving the datatype of attributes
  • First cut of ADL workbench is expected to be ready in 4-6 weeks. Something should be available to demonstrate at next CIMI face-to-face meeting. Will take about 3 months to get right.
  • Update on datatypes work
    • May be able to use more friendly ‘CIMI-synonyms’ for existing openEHR classes and attributes
    • openEHR Concrete datatypes
      • DV_BOOLEAN (FHIR: Boolean)
      • DV_PARSABLE (FHIR: N/A )
      • DV_IDENTIFIER (FHIR: HumanId)
        • issuer
        • id
        • assigner
        • type
      • DV_QUANTITY (FHIR: Quantity)
        • magnitude
        • units
        • precision
      • DV_COUNT (FHIR: Quantity)
        • magnitude
      • DV_PROPORTION (FHIR: Ratio)
        • numerator
        • denominator
      • DV_ORDINAL (FHIR: Choice)
        • value
        • symbol
      • DV_INTERVAL<T:DV_QUANTIFIED> (FHIR: Interval)
        • lower
        • upper
      • DV_DATE (FHIR: HumanDate)
      • DV_TIME (FHIR: dateTime)
      • DV_DATE_TIME (FHIR: dateTime)
    • DV_DURATION (FHIR: Quantity)
      • DV_TEXT (FHIR: Codeable Concept)
        • value
        • mappings
        • language
        • encoding
        • hyperlink
        • formatting
      • DV_CODED_TEXT (FHIR: Codeable Concept)
        • defining_code
      • DV_URI (FHIR: uri)
      • DV_EHR_URI (FHIR: uri)
      • DV_MULTIMEDIA (FHIR: Attachment)
        • alternate_text
        • uri
        • media_type
        • data
        • compression_algorithm
        • integrity_check
        • integrity_check_algorithm
        • size
      • DV_GENERAL_TIME_SPECIFICATION (FHIR: Schedule)
        • calendar_alignment
        • event_alignment
        • institution_specified
      • DV_PERIODIC_TIME_SPECIFICATION (FHIR: Schedule)
        • value: syntax expression with & period & calendar_alignment & event_alignment & occurrences & institution_specified
  • Semantic links
    • Background
      • Potential inclusion of semantic links between parent-child nodes (raised by NHS)
      • CIMI IEC endorsed the requirement “The CIMI reference model must support clinical models that aim to achieve semantic interoperability across a federation of enterprises. CIMI models should not be limited to supporting semantic interoperability within an enterprise and should not be limited to syntactic or structural interoperability across enterprises.”
      • The requirement is to define not only the semantic meaning of each node in the clinical model, but to also define the semantic meaning of the relationship between each parent and child node in the hierarchy. This allows the clinical model to be treated like a semantic graph (with a preferred hierarchical representation, as defined in ADL), and allows queries and expressions to be constructed that navigate the model using the semantic meaning of both the nodes and the relationships between the nodes. This also makes the model more compatible with a UML and/or RDF representational approach. An example of adopting this approach may be demonstrated using a simple Drug Formulation archetype:
               CLUSTER: name = Drug Formulation; meaning = 373873005|pharmaceutical / biologic product|
                               DATA ELEMENT: name = Ingredient [0..*]; meaning = 261217004|Substance|; parent_child_link_meaning = 127489000|has active ingredient|
                               DATA ELEMENT: name = Dose Form [1]; meaning = 105904009|Type of Drug Preparation|; parent_child_link_meaning = 411116001|has dose form|
  • Semantic links (continued)
    • Question: Should this semantic knowledge be represented in the clinical model, or is there a reason to require this semantic information to be included in actual patient data instances themselves?
      • Response from NHS: We can NOT assume the availability of a single repository of archetypes. Someone could receive an instance not knowing what archetype it was derived from.
      • Other comments:
        • Gerard: Sweden also needs semantic links for archetypes, and need to express constraints on possible relationships
        • Tom: If we can assume archetypes of CIMI may be converted to other exchange models, then this semantics must be supported in the archetypes.
        • Shoud investigate whether it is required in the reference model (and therefore in instance data).
      • If they exist only in the model then any query/expressions would require both the model and the instances and in a very heterogeneous environment like the NHS I would see this as problematic.
      • Discussion: Is defining specifications for exchange within the scope of CIMI?
      • Discussion: For those healthcare systems in which it cannot be assumed that the receiving system has access to the archetype definitions, is it possible to bundle the instances together with the models? NHS response: No, each instance should have its own semantic knowledge together with the instance data.
      • Action: Resolution required.
    • Core reference model - other requirements gaps to consider?
      • Add in Generic Entry
      • Draft gap analysis
      • Consider demographics model

Actions

  • Distribute minutes: Linda
  • Continue to work on tooling requirements: Michael, Linda
  • Work on XMI datatype-import issue between BOUML and Enterprise Architect: Tom, Linda
  • Test XMI import into RSA: Galen
  • Continue datatype work: Tom, Grahame, Alan
  • Collaboration with Clinical Modelling taskforce: Linda, Stan
  • Draft requirements gap analysis: Linda