I have explained the profile
I have explained the user authentication model
I really want comments on the profile, especially the Open Issues
OPEN ISSUES
As a Public Comment version there are many issues that have come up during the development that are not fully locked down. Most of them are due to the learning-curve of the committee. Thus I really want constructive comments on the whole Profile but specifically on these Open Issues. The open issues are far more detailed in the document, they are basically:- Restricted “Create” to ONE document, with derived SubmissionSet
- No access to SubmissionSet, Folders, and Associations
- Patient ID is needed as part of URL
- Bring in hData as framework and thus ATOM in GET path for multiple entries?
- Conditional get is not supported due to the differences between the semantics of HTTP and XDS concepts of resource age.
- Do we need more on Security, specifically Audit?
- JSON use of anonymous objects or not?
Why is patient Id needed in the URL? Seems like a fundamental flaw to me.
ReplyDeleteFirst, this is a Public Comment, so please provide your arguments as to why you think it is a "fundamental flaw". To just say that it is a fundamental flaw doesn't tell us why you believe this. Without constructive criticism progress will not happen. I know the deadline is past, but I want to encourage comments.
DeleteThe reason that the patient ID is in the URL is because the information is Patient-Centric. This is a fundamental principle of XDS as well, the Patient ID must always be supplied. By putting it into the URL it becomes more deterministic, and clear that it is required.
There is perception that by putting the patient ID into the URL vs HTTP arguments that there is more security/privacy risk. Ultimately this argument is a nonsequitor as both provide the patient ID, the location doesn't matter. Further the result of a query will be fully specified information. Thus the whole conversation both directions must be protected from Security risks. Moving the Patient ID from the URL to arguments makes no difference. I might argue that by putting it into the root of the URL it is more obvious to designers and deployers.
The Security Considerations identifies this, I don't see any alternative that is better. So please provide more information from your perspective. What is the actual Threat? What is the actual Attack? What is the actual Risk?
John, what is the issues of "JSON use of anonymous objects"?
ReplyDeleteThanks,
Jeff Brandt
I can't claim to fully understand it. It is one of the issues that those that work with JSON will either have no opinion or a strong opinion. Beyond the opinion of those using the results there is little 'worry'.
DeleteThe issue is if we should have named objects or not. The supplement today does not name the objects, so therefore they are considered anonymous objects. An alternative would be to have the entryUUID be included in the name of the object.
today multiple objects can be returned simply enclosed in {}, as a simple 'anonymous' array.:
{{patientID: "144ba3c4aad24e9^^^&1.3.6.1.4.1.21367.2005.3.7&ISO" ,
classCode: {code:" 34133 -9 ",codingScheme:“2.16.840.1.113883.6.1", codeName:“Summary of
....},
{...}}
or we could have named them, which I think looks more like
{XDSDocumentEntry.urn_uuid_14a9fdec-0af4-45bb-adf2-d752b49bcc7d {patientID: "144ba3c4aad24e9^^^&1.3.6.1.4.1.21367.2005.3.7&ISO" ,
classCode: {code:" 34133 -9 ",codingScheme:“2.16.840.1.113883.6.1", codeName:“Summary of
....},
XDSDocumentEntry.urn_uuid_24a9fdec-1af4-55bb-bdf2-e752b49bcc7d: {.....
}}
But, I have not completed my JSON nor RESTful training yet... :-) Hence why I really want COMMENTS.
Also, this is a question where the ITI committee picked one approach and is basically saying "If you see a problem with this, speak up now." We don't see a problem with this.
DeleteOne possible problem (and note that I don't expect this to happen) would occur if an XDS.gamma were to be created that had an incompatibly different kind of DocumentEntry. Then you either need major renaming of resources, or you need a way to indicate the object type in the returned object.
Another possible comment would be to say that all of the XDS object types (Document Entry, Association, Sumission Set) should be available as possible results of a GET. Then there would need to be a way to indicate in the return which type it was. So a return would look like
[documentEntry:{.....}] or [association:{....}].
Is the objection related to the issue MHD-10? We did comment that the implementation of this kind of server is easier if uncertain information like this is handled as a parameter rather than a resource level. "patient querying can get complicated, according to REST practices this sort of complexity can be swept into parameters" That would move the patientID out of the resource URL. It doesn't change any of the security issues. It does potentially affect caching, etc.
Delete