FHIR Chat · Forge bug work around #2 · implementers

Stream: implementers

Topic: Forge bug work around #2


view this post on Zulip Brian Reinhold (Jun 27 2017 at 14:28):

If you are trying to develop profiles using Forge 16.1 that involve handling value[x] cases you are likely running into several problems. These problems become messy when you get into components of an Observation. What happens depends upon the value[x] type one chooses, and it is not consistent as I have found when introducing multiple components. There is an additional secondary problem that I have noticed and that is that element id attributes get dropped.
The best way to deal with this is to have a program like WinMerge that diffs two files side by side. One side will have the file prior to Forge handling it and the second file will be the file updated by Forge. You will find that forge deletes or loses elements when it updates which will give you a corrupted structure definition on reload. But the diff program allows you to restore the stuff that was lost, recovering your previous work.
It is tedious but allows you to go forward.
The major element sets that get dropped are fields like the following:
<element id="Observation.component:supplementalTypesComponent.value[x]:valueCodeableConcept">
<path value="Observation.component.valueCodeableConcept" />
<sliceName value="valueCodeableConcept" />
<definition value="The information determined as a result of making the observation, if the information is a code." />
<min value="1" />
<type>
<code value="CodeableConcept" />
</type>
</element>
<element>
But I have also noticed that elements like this
<element id="Observation.component:supplementalTypesComponent.code.coding:11073MeasurementType.display">
become
<element >
which does not corrupt your structure definition on reload but a lot of info gets lost.


Last updated: Apr 12 2022 at 19:14 UTC