Modular+Specs+Feedback

include component="page" wikiName="siframework" page="ModularSpecTabs"
 * ~ **ID** ||~ **From** ||~ **Issue** ||~ **Response** ||~ **Status** ||~ **Date Submitted** ||
 * 1 || John Donnelly || Should there be required fields in the response? || The DSML specification requires that the query specifies the fields to be returned in the response, therefore there are not any inherently required fields in the response message. || Completed || 5/15/2013 ||
 * 2 || Dan Kazzaz || Could you query a department within an organization? || Yes, the data model allows relationships between organizations. || Completed || 5/15/2013 ||
 * 3 || Kory Mertz || Define Organization – would it be a healthcare facility or a health information exchange? || HIE could be treated as an organization within a directory. || Completed || 5/15/2013 ||
 * 4 || Bob Dieterle || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">When we talk about the individuals involved with the organization, we are not necessarily talking about providers. Organizations can involve payers, providers, etc. || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Nothing in the specification limits the types of organizations that can be included in the directory. || <span style="font-family: Calibri,sans-serif; font-size: 15px;">Completed || <span style="font-family: Calibri,sans-serif; font-size: 15px;">5/15/2013 ||
 * 5 || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Dan Kazzaz || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Would it be problematic if we did not permit anonymous queries? || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Current specification allows for anonymous queries. Local implementations can decide not to allow anonymous queries. We welcome feedback on this. || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Open for Feedback || <span style="font-family: Calibri,sans-serif; font-size: 15px;">5/15/2013 ||
 * 6 || <span style="font-family: Calibri,sans-serif; font-size: 15px;">Bob Dieterle || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">What has been done with federation? || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">The requirements should be architecturally neutral and should not impede federation. There will be further discussions to address methods on federation. || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">To be discussed on the next public call || <span style="font-family: Calibri,sans-serif; font-size: 15px;">5/15/2013 ||
 * 7 || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Bob Dieterle || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">There cannot be a query on the certificate identifier because the data elements within the certificate are not differentiated. || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">We will look into this further. || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Team to discuss internally || <span style="font-family: Calibri,sans-serif; font-size: 15px;">5/15/2013 ||
 * 8 || Marty Prahle || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Is testing going to lead to certification in the transactions between requestors and responders? || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">ONC does not have plans for that at this time. We have not yet agreed to do a testing tool for this project. || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Completed || <span style="font-family: Calibri,sans-serif; font-size: 15px; line-height: 1.5;">5/15/2013 ||
 * 9 || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Lin Wan || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">IWG Syntax and IWG Comments should be updated || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Currently working towards updating new versions of specifications with the artifacts posted. Updated artifacts to reflect changes published in IWG Version 1.1 will be posted to the Public Page. || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">In progress || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">6/5/2013 ||
 * 10 || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Manoj Goel || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Are you planning on assigning OIDs that are not defined? || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">The attributes which do not have assigned OIDs have been assigned temporary OIDs. We are in contact with IHE to address this issue. || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Pending IHE completion || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">6/5/2013 ||
 * 11 || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Lin Wan || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Has there been a dialogue with the vendors? If so, are we harmonizing? || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">We have been in touch with Mirth and other vendors who are working with the Western States. The notices of the public calls and the availability of materials on the WIKI have been widely distributed and vendor comments will be welcome through this forum. || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">In progress || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">6/5/2013 ||
 * 12 || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Lin Wan & Corrina Burnley || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Including a duplicate requestID in HPDPlusRequest and HPDPlusResponse introduces the potential for inconsistency with the BatchRequest or BatchResponse, if it contains a different request ID value. Rules will need to be identified for how to handle this situation.

<span style="font-family: Calibri,sans-serif; font-size: 11pt;">Alternatively, HPD+ specifications could add the constraint that the requestID is required. This would not be captured in the XSD, but could easily be validated with a schematron. IHE uses this method of incorporating additional constraints over what is specified in XML schemas, and using schematron validation for testing. || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">We are reviewing the specifications to determine if a change is needed. || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">In progress || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">6/5/2013 ||
 * 13 || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Santhosh Gnanasurian || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Is address a mandatory attribute? If so, how do you pass it? || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">The MSPD team has decided not to make any of the attributes mandatory. This way, it is the implementer’s decision to make any attributes mandatory, as necessary. || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Completed || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">6/26/2013 ||
 * 14 || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Bob Dieterle || What are you doing with federation? || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">The MSPD project has developed a specification using a new WSDL, which can be found here. || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Completed || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">6/26/2013 ||
 * 15 || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Don Jorgenson || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">What is the status of the implementation work going on? || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Testing and Implementation is currently ongoing as we are testing those federation capabilities. || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">In progress || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">6/26/2013 ||
 * 16 || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">Bob Dieterle || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">How is credentialID going to be used? Are you distinguishing between Professional Credential and Electronic Credential? || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">The MSPD team is currently discussing how to distinguish these two types of credentials. || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">In progress || <span style="font-family: Calibri,sans-serif; font-size: 11pt;">6/26/2013 ||
 * 17 || Lin Wan || The clarifications on data model and requirements are great.

The proposed changes to the WSDL and message schema are not backward compatible, and therefore should go back as IHE change proposals so that we don't create diverging standards.

The proposed HPDPlusMetadata should have some specific examples/constraints on the properties that were considered to demonstrate the use cases that lead to the change. Without specific constraints/examples, it will be hard for implementers to know what to send and what to expect in this new element. || Submitting the revised web service as an IHE change proposal for HPD Plus is being actively considered.

Your recommendation that the metadata properties should be constrained down to an enumeration has been noted.

The TI currently has two defined: doNotFederate and flattenResponse. However, their functionality is currently not implemented in the backend and we do not test against them (there was never a full consensus on their precise functionality/desirability). Documentation regarding how the new metadata + errors are meant to work (in addition to the documentation that is in the code + XML schema) is available on the MSPD page. || In progress || 7/15/2013 ||
 * 18 || Lin Wan || The new element HPDPlusError is similar to ErrorResponse in DSML except that it added some new values for the "type" attribute: e.g. FederationLoop, organizationalQueryRulesViolation. Can those be handled in other with details in the "message" & "detail" elements? || It would be possible to constrain the content of the message and detail child elements by policy (and perhaps some Schematron). Using the detail child element would probably be a better idea since its content is a single element of type xsd:any (any XML element, from any XML namespace). We could define a new XML type of type(s) with whatever structure would be useful.

However, this would not solve the core problem inherent in using DSML v2: the Directory must still combine all sub-response(s) of any and all sub-request(s) to data source(s) and/or federated peer(s). If we came up with a good structure to put inside the detail(s), this would improve things, but we would, in effect, be accomplishing the same thing ass HpdPlusError, but in a more difficult to enfore, less straightforward manner.

Another option for error handling would be to define/use new HPD Plus Soap Faults for web service level errors (no change for datasource errors). However, this would necessitate changes to the WSDL, so it may not be any more desirable for those individuals/organizations that want to keep it the same. || In progress || 7/15/2013 ||