CTS2/doc/CTS2 SFM CodeSystemAttributes

Prev Contents Next

The diagram below contains the attributes described in the CTS2 SFM and the those in the CTS2 PIM. The sections that follow explain the differences between the two models and the rationale for the differences.

SFM	PIM	Reason
id - type ISO OID	about - type ExternalURI	The CTS2 PIM was required to address the needs of many communities - the vast majority of which used URI's as identifiers. The developers were faced with a choice of: creating two fields one for OID and one for URI, both optional adding an id type tag (OID, UUID, URI, DOI, etc.) and making the key two fields leveraging the fact that the URI scheme already supported a type field. The decision was made to go with option 3, meaning that HL7 OID's need to be "uri'ized" in the CTS2 model - 2.16.840.1.113883.6.1 in the MIF becomes urn:oid:2.16.840.1.113883.6.1 in CTS2. One of the challenges that the CTS2 PIM modelers faced is differentiating the URI of the description (e.g. http://informatics.mayo.edu/cts2/HL7AdministrativeGender) from the URI of the resource being described (e.g. urn:oid:2.16.840.1.113883.6.1). The term, "id" didn't make this clear, so "about" was substituted in its place.
description	resourceSynopsis	The CTS2 ROA approach emphasized that the various CTS2 model elements contained descriptions of the various resources, not the resources themselves. A CodeSystemCatalogEntry may describe SNOMED-CT, but it clearly isn't SNOMED-CT itself. This distinction turned out to be quite important in some situations. The problem, however, is that the term description was already used to characterize all of the CodeSystemCatalogEntry metadata, so we needed a different term for the block of text that summarizes and/or describes the resource in a given language. The term resourceSynopsis was chosen as a substitute.
administrativeInfo	codeSystemName, codeSystemCategory, ontologyDomain, ...	The CTS2 PIM felt that the "placeholder" in the SFM needed to be made explicit where industry accepted naming and type standards were in place. The various elements, which you will note are almost all optional, are drawn from a variety of sources including LexGrid, LexEVS, RDF and OWL, the Dublin Core, the Ontology Metamodel Vocabulary (OMV), BioPortal, etc. property provides a slot for including additional information not named in the other components described above.
CodeSystemSupplement		CodeSystemSupplement explicitly calls for a name (an attribute that is, curiously, not spelled out in CodeSystem. provenanceDetails appear to be synonymous (?) with administrativeInfo and effectiveDate is a characteristic of a version, not a code system itself. We have concluded that CodeSystemSupplement requires all the characteristics present in Codesystem (especially as CodeSystemCatalogEntry makes many of the provenanceDetails explicit), needs to be versionable, and needs to reference specific CodeSystemVersions in addition to target CodeSystems

Prev Contents Next