RIM based ITS

Introduction

The RIM based ITS (or RS XML ITS, a term used by the RIMBAA WG) is an ITS that is based on 'pure RIM semantics', i.e. an ITS that defines an XML syntax which allows for the XML to be processed solely based on its contents (and not on Class Clone names, or knowledge of templates/interactions used).

Rationale

Reasons for the ITS (in no particular order):

• One single XML schema
• For use in exchanges between RIMBAA applications (where clone names are totally irrelevant)
• To store XML instances in a XML-database (e.g. DB2 PureXML) and query them using XQuery
• To validate the validity of CIMs: if one is NOT able to roundtrip an XML instance of the CIM (XML ITS 1.1. version -> RIM ITS version -> XML ITS 1.1 version, using MIF based mapping) the CIM uses a model that carries semantics in its Clone names.

Characteristics of the proposed ITS

We currently have the XML ITS R1. It has the following properties:

• element names identify Rim clone classes
• properties that are defaulted in the Rim specific model (CIM) are not represented in the instance
• the order of associations in the instance is fixed for predictability - based on element names
• whether something is play or scoper etc is implicit (in the rim specific model) rather than in the instance
• You need the MIF to convert from the instance to a general RIM graph.

The RIM serialization would have different properties:

• element names identify the RIM back bone associations
  • The XML element names (related to classNames, not attribute names) only serve to provide a syntax, they carry no semantics, and are not used in determining the semantics of the artefact content.
• properties that are defaulted in the general rim are not represented in the instance
  • Almost all structured attributes (e.g. classCode, moodCode) will be present in all instances
• the order of the associations is irrelevant: only their semantics matter
• player/scoper etc is explicit in the instance

Discussion

(Peter Hendler): If it comes true it would make communication between RIM based applications a lot less trouble. As you know, our MIF parsers and our meta classes add a lot of complexity to the reference Java SIG API and if we could just send messages already based on the RIM backbone that would be fantastic. If we wanted we could include the clone class names (optionally) as attributes. We wouldn't need them to process the messages and put them into a database but maybe they'd be nice for readability.

• 2010-01-20 Joint ITS/RIMBAA WG meeting, hosted by the ITS WG.
  • Grahame: sees three uses: straight RIMBAA, use in messaging apps that don't want to read MIF to import data, use in CDA R3.
  • Conversion from XML ITS to RIM ITS is easy; conversion from RIM ITS to XML ITS is difficult (if one doesn't include cloneNames as an informational attribute) is difficult.
  • Keith: useful, yes (CDA R3), possible: yes. Jean Duteau: requirement for a single schema; deep validation done within application anyway. Ann: agrees with goodness of this, but we shouldn't be carried away by this. We should not set up the two ITSs to be in competition. Define "what this is good for", instead of stating that this is the only way forward. Keith: we have different ITSs, used for different purposes. Rik: like that instance doesn't use clone names, also a learning tool that one shouldn't assign semantics to clone names. Grahame: this helps to move semantics away from the techies to where it belongs.
  • ITS WG MOTION 2010-01-20: To ballot the RIM ITS (on normative track, status to be determined) in the May ballot cycle. (Grahame/Keith, 18-0-1)
  • Paul Knapp: ask Mohawk to create a reference implementation. Grahame: I already have one..

Transformation between the XML ITS R1 and the newly proposed RS XML ITS

In terms of the Technology matrix this is the mapping between CS and RS (and vice versa)

• To match the rim object graph to a specific rim model (i.e. an HMD) (which is required to serialise in that form), you must match the elements to the model by running validation in reverse - it is this kind of association because it meets the constraints that this association has. And you need the MIF for that, of course.

Example

Below an example of a NE2008 interction serialized according to a (draft version of) a RIM ITS. Note (for example) the use of element names like outboundrelationship, participation and role instead of clone class names.

<?xml version="1.0" encoding="UTF-8"?>

<rim-graph xmlns="urn:hl7-org:v3-rim" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" model="QUPC_IN043200NO" version="0226">
  <content xsi:type="Message" xsi:schemaLocation="urn:hl7-org:v3 ../schemas/QUPC_IN043200NO.xsd">
      <!--  Unique identification of this message instance. Root derived from that of the sending application  -->
    <id root="2.16.578.1.34.1.922.3" extension="93829283673"/>
    <creationTime value="20080618105503"/>
    <versionCode code="NE2008"/>
    <interactionId root="2.16.840.1.113883.1.6" extension="QUPC_IN043200NO"/>
    <processingCode code="P"/>
    <processingModeCode code="T"/>
    <acceptAckCode code="NE"/>
    <communicationFunction xsi:type="CommunicationFunction" typeCode="RCV">
      <entity xsi:type="Device" classCode="DEV" determinerCode="INSTANCE">
              <!--  Receiving software application. Helse Vest assigned application identifier  -->
        <id root="2.16.578.1.34.1" extension="805"/>
      </entity>
    </communicationFunction>
    <communicationFunction xsi:type="CommunicationFunction" typeCode="SND">
      <entity xsi:type="Device" classCode="DEV" determinerCode="INSTANCE">
              <!--  Sending software application. Helse Vest assigned application identifier  -->
        <id root="2.16.578.1.34.1" extension="922"/>
      </entity>
    </communicationFunction>
    <conveyedAcknowledgement xsi:type="Acknowledgement" typeCode="AA">
          <!--  Affirmative acknowledgement  -->
      <acknowledges xsi:type="Message">
              <!--  .. related to this original message ID  -->
        <id root="2.16.578.1.34.1.805.1" extension="080629150002_305"/>
      </acknowledges>
    </conveyedAcknowledgement>
    <controlAct xsi:type="ControlAct" classCode="CACT" moodCode="EVN">
      <participation xsi:type="Participation" typeCode="AUT">
              <!--  Identifies the software application responsible for sending this message  -->
        <role xsi:type="Role" classCode="ASSIGNED">
                  <!--  Sending software application. Helse Vest assigned application identifier  -->
          <id root="2.16.578.1.34.1" extension="922"/>
        </role>
      </participation>
          <!--  Zero or more encounters are found: this interaction contains zero or more subject/encounterEvents  -->
      <outboundRelationship xsi:type="ActRelationship" typeCode="SUBJ">
        <target xsi:type="ActHeir" moodCode="EVN" classCode="REG">
                  <!--  This registry doesn't support  registration IDs  -->
          <id nullFlavor="UNK"/>
          <statusCode code="active"/>
          <participation xsi:type="Participation" typeCode="CST">
            <role xsi:type="Role" classCode="ASSIGNED">
                          <!--  Organization responsible for the registry, here: Helse Vest  -->
              <id root="2.16.578.1.34.1000.5" extension="983658725"/>
            </role>
          </participation>
          <outboundRelationship xsi:type="ActRelationship" typeCode="SUBJ">
            <target xsi:type="ActHeir" classCode="ENC" moodCode="EVN">
              <id root="2.16.578.1.34.1.922.1" extension="300807"/>
              <code code="IMP" codeSystem="2.16.840.1.113883.5.4"/>
              <statusCode code="completed"/>
              <effectiveTime>
                <low value="20070403"/>
                <high value="20070411"/>
              </effectiveTime>
              <participation xsi:type="Participation" typeCode="SBJ">
                <role xsi:type="Patient" classCode="PAT">
                  <id root="2.16.578.1.34.1000.1" extension="24109642356" assigningAuthorityName="F-Number"/>
                  <statusCode code="active"/>
                  <player xsi:type="Person" determinerCode="INSTANCE" classCode="PSN">
                    <name use="L">
                      <given>Jan</given>
                      <given>Helge</given>
                      <family>Norekval</family>
                    </name>
                  </player>
                </role>
              </participation>
              <participation xsi:type="Participation" typeCode="PRF">
                <role xsi:type="Role" classCode="ASSIGNED">
                                  <!--  Code to identify the type of unit / specialty  -->
                  <code code="KIR" codeSystem="1.2.999999999999"/>
                                  <!--  Identification (optional) and name (mandatory) of the unit/department  -->
                  <player xsi:type="Organization" classCode="ORG" determinerCode="INSTANCE">
                                      <!--   RESH identifier of the unit/department. RESH  = Register for Enheter i SpesialistHelsetjenesten   -->
                    <id root="2.16.578.1.34.1000.4" extension="5067"/>
                    <name>Kirurgisk Avdeling </name>
                  </player>
                </role>
              </participation>
              <outboundRelationship xsi:type="ActRelationship" typeCode="PERT" contextConductionInd="true">
                <target xsi:type="Observation" classCode="OBS" moodCode="EVN">
                                  <!--  Primary diagnosis  -->
                                  <!--  Code to indicate this is an observation of type discharge-diagnosis  -->
                  <code code="DISDX" codeSystem="2.16.840.1.113883.5.4"/>
                                  <!--   Diagnosis code, from the Norwegian version of ICD-10 -->
                                  <!--  Displayname SHOULD be sent by sender of the message. Receiver may use this to display the description to the human reader  -->
                  <value xsi:type="CD" code="I23.9" codeSystem="2.16.578.1.12.4.1.1.7110" displayName="Pulmonary decease"/>
                  <inboundRelationship xsi:type="ActRelationship" typeCode="PERT">
                                      <!--  Secondary diagnosis  -->
                    <source xsi:type="Observation" classCode="OBS" moodCode="EVN">
                                          <!--  Code to indicate this is an observation of type discharge-diagnosis  -->
                      <code code="DISDX" codeSystem="2.16.840.1.113883.5.4"/>
                                          <!--   Diagnosis code, from the Norwegian version of ICD-10 -->
                                          <!--  Displayname SHOULD be sent by sender of the message. Receiver may use this to display the description to the human reader  -->
                      <value xsi:type="CD" code="Q23.7" codeSystem="2.16.578.1.12.4.1.1.7110" displayName="Asthma"/>
                    </source>
                  </inboundRelationship>
                </target>
              </outboundRelationship>
            </target>
          </outboundRelationship>
        </target>
      </outboundRelationship>
      <queryEvent xsi:type="QueryAck">
              <!--  Unique identification of this query conversation. Copied from the query interaction  -->
        <queryId root="2.16.578.1.34.1.805.1" extension="080629150002_305"/>
        <queryResponseCode code="OK"/>
        <resultCurrentQuantity value="1"/>
        <resultRemainingQuantity value="0"/>
      </queryEvent>
    </controlAct>
  </content>
</rim-graph>