This portal provides an open platform for user feedback and product change requests. Anyone can add an idea and remain as a Guest, but please consider signing up so that others can see who has created the ideas!
Note: this is a public facing web portal, any text here can be viewed by anyone over the internet, so please consider carefully the content you wish to share and please do not post anything of a sensitive nature.
The current validation does not validate against all Invariants, for example the STU3 specification for Period has ‘+ If present, start SHALL have a lower value than end’ invariant, however, Connect FHIR appliance 3.9.4 allows a data provider to create a resource where period.end is before period.start.
Enforcing invariants, and throwing an OperationOutcome rather than allowing invalid data would be helpful to the development process as it would highlight inaccuracies in the local build from which the resources are derived, and ensure all data conforms to the base standard.
Being able to specify invariants as part of any new Interweave Data Standards (i.e. using an ElementDefinition) would also enable more complex business rules to be included in the profiles (e.g. must have an X when Y=’abc’)
Hi Ian
This isn’t causing a particular problem, but it does mean we will need to pay particular attention to the build and test of our data feeds to ensure they capture any scenario which could result in data that breaks one of the invariant rules … even with the best will in the world I suspect we will miss some cases.
That’s probably not a huge risk at the moment, it might just mean the data looks a bit odd in a user interface … the longer-term risk will be when we want to share our data with 3rd parties / national solutions, i.e. that might or be able to handle requests/response that contain resources which break a rule.
Hi Stephen, we think this falls into the category of good, but big scary idea ;-) so I've categorised as a future consideration.
Ideally once we have a first iteration of the FHIR standards across all resources we can loop back to consider this and the work that Exchange would need to do to support it.
We also need to consider the opportunity cost of doing this vrs current priorities and roadmap items.
Is this causing particular problems atm or is it sufficient to rely on source data validation and testing?