New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect $validate OperationDefinition in generated Conformance resource #379

Closed
lawley opened this Issue Jun 8, 2016 · 2 comments

Comments

Projects
None yet
2 participants
@lawley
Contributor

lawley commented Jun 8, 2016

We have three Providers (ConceptMap, ValueSet, and CodeSystem) that each implement both type and instance $validate with @Validate annotations, however the single OperationDefinition included in the Conformance metadata resource lists the type of the resource parameter as CodeSystem.

It also lists 6 entries for type (two per resource type). It seems that the type/instance distinction is being lost somewhere.

Only in parameters are generated; no out parameter.

Finally, instance is set to true, but the defn seems to cover both type and instance (as per 6 type values); should there be separate OperationDefinitions for each?

@jamesagnew

This comment has been minimized.

Owner

jamesagnew commented Jun 11, 2016

This is an interesting issue. OperationDefinition.parameter.type doesn't allow multiple values, so I guess really this does need to be one OperationDefinition per resource type you can validate. That's easy enough to fix.

Finally, instance is set to true, but the defn seems to cover both type and instance (as per 6 type values); should there be separate OperationDefinitions for each?

The definition of OperationDefinition.instance is "Indicates whether this operation can be invoked on a particular instance of one of the given types.". Given the word "can", I take this to mean that

  • a value of true means the operation can be applied at both the type and instance level
  • a value of false means that the operation can be applied at the type level
  • there is no way of indicating that the resource can only be applied at the instance level

This seems worth raising on the FHIR channels for clarification, but based on the current wording I don't think it makes sense to split the instance/type definitions into 2. Thoughts?

Will commit a fix to the first part shortly.

@jamesagnew

This comment has been minimized.

Owner

jamesagnew commented Jun 11, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment