Should all Entity's be required to have an id?

[larrybabb]

In a recent PR the requirement of the id attribute on InformationEntity was promoted to the top-level ancestor Entity class. This change will require every Entity descendant to carry an id property in all valid GKS json files.

Currently, VRS has several SequenceExpression classes that inherit from Entity which do NOT use the id property.

Should we make a rule that clearly states that one should only inherit from Entity when defining an identifiable entity? If so, then we will need to modify VRS' SequenceExpression classes to be objects instead of Entitys.

Or should we not require id on Entity and leave this as an implementation choice when constructing valid json messages with classes that are inherited from Entity?

[larrybabb]

@ahwagner just as a related point. I'm not sure why we made SequenceExpression inherit from Entity. I think maybe this discussion is a good defining point of what is an Entity and what isn't. If everything is an Entity then we should make all our classes inherit from it (e.g. Expression, Coding, etc...). If not, then maybe the determining factor is that only classes that require and id when sharing in json should be Entitys.

[ahwagner]

When we started working on the VRS 2.0 model, you and I had some discussions about aligning this with FHIR. We decided to model Entity in the same way as a FHIR Element, which allowed for broad and standardized extensibility. As with the Element class, the Entity class we used contains an id that is not required.

[larrybabb]

ok. then id should NOT be required. Maybe we should correlate the InformationEntity to the FHIR Resource?

FHIR is a tricky think to follow since they really don't require much of anything until you get down to specific profiles or concrete Resources.

Maybe we should nix the whole idea of require id ? What say you @ahwagner and @mbrush ?

[ahwagner]

I agree, we should not require ID.

[larrybabb]

@mbrush As much as I do not want to re-raise the identifier vs id discussion, I would like to point out that I have been viewing id as less of an identifier (in FHIR terms) than an id (in FHIR terms). If you are thinking of id as a FHIR-like identifier that may be conflating the issue of whether this field should be required. (Just a thought)

[mbrush]

Regarding alignment patterning after FHIR, my understanding is as follows:

• FHIR.Element is the parent type for primitive and complex data types. It is not a parent of FHIR.Resource.
• FHIR.Resource is the root of all FHIR classes representing things of interest in the clinical domain.
• I consider the gks-core-im.Entity class to be analogous to FHIR.Resource - as it is root of all classes representing things of interest in our domain of discourse - including Information Entities, Activities, Agents, etc., and Domain Entity classes including Variation, Gene/Condition classes, etc.
• FYI @larrybabb the id property is actually not required in FHIR.Resource (cardinality is 0..1).

Regarding our models:

• I don’t feel strongly about making id required in our Entity class.
• On the one hand I have erred toward more permissive constraints in the core-im. I think that we will want to enforce stricter constraints in the Standard Profiles that actually get used to create data.
• On the other hand, to the extent that we can identify attributes that are generally good practice to require, I think we should do so upstream in the core-im rather than rely on each standard profile to do it. For consistency.
• I generally like the idea of Entity being the root of things that have ids. In SEPIO, I defined the notion of Utility Class to root classes that are more like complex data types, which do not have ids (Coding, Extension, RecordMetadata). These objects support organization of related data within primary class structures. But this abstract Utility class did not make it into the gks-core-im.
• All this said, I defer to you two about whether we should enforce id at the Entity class level right now. No harm in making it optional for now, and revisiting later.

Finally, @larrybabb re id vs identifier

• My view is the same as yours. I hope this is clear from the description and comments on the Entity.id attribute.
• An identifier attribute is defined in the sepio-im, and ready for inclusion in the gks-core-im if/when the time comes.

[larrybabb]

Ok. I will take the requirement off of id for now. I like the more permissive model for the time being. If and when we determine it useful to require an attribute we will make a collective decision.