Survey - Proposed API change to make related items easier to work with... you've been working with related items, you may have found that it's a bit inconvenient to use right now. Specifically: To set up a two-way-link between objects, you need to insert one, insert the second with related items, and then update theen-USTelligent Evolution Platform Developer Build (Build: 5.6.50428.7875)re: Survey - Proposed API change to make related items easier to work with..., 30 Jul 2008 13:31:13 GMT91d46819-8472-40ad-a661-2c78acb4018c:8791354John Lohan<p>Hello Eric,</p> <p>I don't think introducing ClientId makes the problem any simpler. Rather, I'm more comfortable with the current implementation. Less the number of GUIDs we come accross, less the confusion.</p> <p>But let me tell you my main concern.</p> <p>I can relate one thing with another, but how do I specify what is the relationship?</p> <p>E.g. I can relate an Allergy with a Procedure. But how do I specify that the related GUID is referring to an allergy?</p> <p>Say, I use RelationshipType string.</p> <p>But how will the other applications know what is the meaning of the string?</p> <p>Also, how do I know that this relationship was added by me? In this case, every application should carefully prefix the RelationshipType string with some unique string (e.g. name of the application).</p> <p>This doesn't sound a good mechanism, since we are at the discretion of each and every application using HV.</p> <p>As per my opinion, we should have another member of HealthRecordItemRelationship class named RelatedItemType of type HVThingTypesEnum, which is an enum of all the thing types (including application-specific).</p> <p>And preferably it should be a non-nullable field.</p> <p>Let me know if you thing this will add any value.</p><div style="clear:both;"></div><img src="" width="1" height="1">