Page History

...

The RIM core MIF expresses a number of tags under the root static model that are defined as subject area packages.  We know from the defining xsd that these are sub-packages and we can see that one sub-package can be nested within another, implying that one package is a subclass of another.  Furthermore some sub-packages define contained class tags implying yet another area of sub classification.  We can deduce relationships from these that will allow us to map to LexEVS associations.  When the contained classes are elsewhere fully defined in the RIM core MIF, attributes and annotations are declared that normally might map to Entities and Entity Properties respectively in LexEVS.  However, the attribute tagged values will sometimes bear references to a data type tag or a concept domain tag, both of which are defined in the vocabulary core MIF and correlate to the the code systems also defined there.  We could pre-correlate this relationship by persisting this as a LexEVS association making the attribute a first class entity, or we could leave it as a property and post-correlate the relationship for interested users through a series of LexEVS calls.  Some instances of contained classes are otherwise defined as concepts in code systems designated by the definingVocabulary tag in the RIM core MIF.  This is another relationship between files that will need consideration for definition in LexEVS.  Some few values are expressed in the RIM core MIF as attributes in an endPoint tag, if these should be expressed in LexEVS, some determination will have to be made. Value sets are expressed in the vocabulary core MIF that are not currently being loaded to LexEVS. 

The vocabulary core MIF will map in a manner similar to the  previous load, with some exceptions.  Relationships will be defined with names noted in the concept relationship tag attribute "relationshipName" where previously all relationships were named "hasSubtype."  Otherwise, relationships with the code system will be created based on containment and can maintain the hasSubtype designation.  Most hierarchies defined in LexEVS provide a leaf-to-root resolve direction.  The HL7 load was an exception.  This should be revisited in this design. It appears that these value sets are tied to code systems defined in the MIF and that other values from other coding schemes are sometimes combined with them when applied using the unionWithContent tag.  An evaluation of these will need to be made to determine how and whether to load these as value sets in LexEVS.

We will otherwise map the definition tag to a definition type property in the LexGrid and concept property tag attributes will define the numerical portion of the unique identifier where the concept property name is "internalId."  The code tag will define the other portion of the unique identifier using the code attribute to concatenate to the end of the numerical identifier preceded by a colon.  These should complete conformance, to a certain extent, with with old LexEVS load of the RIM from the MSAccess database.

...

1. How value sets are defined in the vocabulary core MIF and how and whether they will be mapped to LexEVS.
2. How much of the RIM core MIF should be mapped to LexEVS, if any, and whether relationships implied in the defininigCodeSystem, dataType and conceptDomain tags should be expressed in LexEVS.
3. whether attributes in the RIM core MIF under contained classes be first class entities.
4. whether endPoint designations should somehow be expressed in LexEVS.
5. verification of all mapping proposals with stakeholders.

Implementation Design

The loading application will parse the xml and stream elements to be marshaled into coding scheme, entity and association elements where they can be tied together as a coding scheme object and loaded to the LexGrid data base.

...