5.13.0 Beta 1

Version 5.13.0 introduces several enhancements and bug fixes to FHIR export:

• New mapping feature to indicate that certain elements should not produce profiles (e.g., Patient or Encounter)
• Simplified names and titles of profiles, extensions, logical models, value sets, and code systems
• Allow mappings of Coding to code or CodeableConcept (standardhealth/shr-cli#131)
• Properly handle cardinality when mapping to extensions (standardhealth/shr-cli#136)
• Remove redundant/invalid targetProfile property from DSTU2 type elements

To use the new feature to indicate that a certain element shouldn't produce a profile, even if there are meaningful differences, add (no profile) after the top-level element mapping but before the colon. For example:

Patient maps to http://fhir.org/guides/argonaut/StructureDefinition/argo-patient (no profile):
	Person.ActiveFlag maps to active
	Person.HumanName maps to name
	Person.AdministrativeGender maps to gender
	Person.PhotographicImage maps to photo
	Person.Address maps to address
	Person.ContactPoint maps to telecom
	Person.LanguageUsed.Language maps to communication
	Person.DateOfBirth maps to birthDate
	Person.MaritalStatus maps to maritalStatus
	Person.BirthSex maps to http://fhir.org/guides/argonaut/StructureDefinition/argo-birthsex
	Person.Race maps to http://fhir.org/guides/argonaut/StructureDefinition/argo-race
	Person.Ethnicity maps to http://fhir.org/guides/argonaut/StructureDefinition/argo-ethnicity

The above mapping would prevent a profile for shr-entity-Patient from being built. This means that any other profiles that would reference an shr-entity-Patient will reference the argo-patient instead.

Note that this may have implications for code generation and the currently in-progress toFHIR and fromFHIR capability. By keeping the individual mapping statements in the mapping, some mapping data will be logged for toFHIR/fromFHIR to use, but if there are items not in argo-profile at all, then not much can be done.