Menu

ciem schemas

2014-10-20
2014-10-21
  • bobuddiebob

    bobuddiebob - 2014-10-20

    Hi,

    I’m curious as to whether or not these are the official CMS CIEM schemas or if they were created just for this project? It looks like pretty much every element has an unbounded number of occurrences which doesn’t really make sense. This becomes particularly problematic when generation java classes from the schemas as all of the fields in the generated classes become Lists . Is there an updated set of xsd files that have a more granular set of cardinalities associated with the elements? OR possibly a data model that describes th e cardinalities so I could apply them to my local copy of the schemas?

    Thanks

    Rob

     
  • Kristen Mork

    Kristen Mork - 2014-10-21

    Yes, this is the official CMS Information Exchange Model (CIEM), which derives from the National Information Exchange Model (NIEM).

    If you look at NIEM [1], you will see that there are virtually no cardinality restrictions (i.e., elements and attributes are optional and elements have no maximum cardinality). In NIEM, the only exception is structural elements mandated by the NIEM Naming and Design Rules (e.g., an augmentation object has maximum cardinality of one). In CIEM, there are some elements with a maximum cardinality because the element contributes to the very definition of the entity being described (e.g., an Issuer can only be licensed in a single state, by definition).

    These cardinality rules are deliberate. Both NIEM and CIEM are reference models, from which exchange models derive. Any constraints (such as cardinality restrictions) that appear in a reference model must apply to every information exchange. Virtually any cardinality constraint you might conceive of will be violated by some information exchange. For example, whereas all persons have a Birth Date, not every exchange model will use that element (i.e., it cannot be mandatory in the reference model). Similarly, a person cannot have more than one Birth Date, until the system has to accommodate conflicting information (e.g., SSA claims one date and DHS claims a different date). In short, the cardinality rules deliberately accommodate a wide range of possible exchange models.

    Peter

    [1] http://www.datypic.com/sc/niem21/ss.html is my favorite way to browse NIEM.

     
  • bobuddiebob

    bobuddiebob - 2014-10-21

    So is the basic idea then that the reference models are then further restricted along the lines of HL7 CDA documents where there is the overarching CDA schema but actual uses are based on Implementation Guides for specific domains? You mentioned that the exchange models are derived from the reference model, are there schemas or IGs that specify the derived models?

    Thanks

     
  • Kristen Mork

    Kristen Mork - 2014-10-21

    That's a fair analogy. To create a CIEM-conformant exchange model one a) creates a subset model from CIEM, b) adds an augmentation model with new concepts, and c) introduces constraints. The result is an XML Schema for a specific information exchange (often a web service).

    For example, a simple SSN verification service might incorporate Person, PersonName, PersonFullName, PersonBirthDate and PersonSSNIdentification (all from NIEM) as the inputs to the service. The response might use SSNVerificationCode from CIEM or introduce a new specialization of VerificationCode. In addition, it's likely that Person is required with no maximum cardinality and that the remaining elements have cardinality of exactly 1.

    The specific derived models are owned by the entities that create CIEM-conformant web services and are not in the public domain (by default).

     

Log in to post a comment.