Talk:Query for Existing Data: Difference between revisions
| Line 9: | Line 9: | ||
==Issue Log== | ==Issue Log== | ||
===Open Issues=== | ===Open Issues=== | ||
==== One WSDL or two? ==== | |||
HL7 and IHE specifications for Web Services would indicate that the formal contract defining the behavior of the service be described in a single Web Services Definition. However, a WSDL that conforms to HL7 specifications is overly complex for engineering use. I would recommend supplying one WSDL that is the formal contract, and a second WSDL for engineering use, to simplify the creation of client proxies. | |||
[[User:Kboone|Kboone]] 15:45, 8 February 2007 (CST) | |||
====Should Accept and Application Acknowledgements be supported? ==== | |||
The web service responds to queries with results. This is a very simple request/response message exchange pattern (MEP), which obviates the need to support application or accept acknowledgements. If the request succeeds, then the response serves as an application level acknowledgement. So, I have decided to not use either of these. | |||
[[User:Kboone|Kboone]] 15:45, 8 February 2007 (CST) | |||
==== Following the HL7 Shoulds in naming? ==== | |||
The HL7 Web Services profile provides guidance about how to name various components of the service description. No rationale for this guidance is provided, and the names are not easily understood by application developers. Therefore, I have followed the spirit but not the letter for this guidance, using the human readable names derived from the HL7 Ballot materials, instead of the interation identifiers. Note however, that the names of the Elements carried in the soap:Body conform to the "Shall" requirements, in that they do use the HL7 interaction identifiers for the name of the message element. | |||
[[User:Kboone|Kboone]] 15:45, 8 February 2007 (CST) | |||
====Number of Actors?==== | |||
Should there just be a single Clinical Data Source Actor, with optional transactions, or should there be several different kinds of actors? Vitals Data Source, Lab Data Source, Medication and Immunization Data Source, Problems and Allergies Data Source? Increasing the number of actors will increase the number of WSDLs that are needed, but would allow greater flexibility in the profile. A Medication and Immunization Data Source might be integrated with RxHUB or an immunization registry, as well as with an EHR. I think I'm in favor of this approach (but it will mean that there is substantial editing to do). Should the medication data source be separated from the Immunization data source? I think problems and allergies stay together, but am not certain. | |||
[[User:Kboone|Kboone]] 15:45, 8 February 2007 (CST) | |||
====Medications and Immunizations?==== | |||
Do we leave this transaction in Volume 1, and just not implement it this year? The scope issue is that the standards may not support the medication query transactions yet. | |||
[[User:Kboone|Kboone]] 15:45, 8 February 2007 (CST) | |||
===Closed Issues=== | |||
===Closed Issues=== | ===Closed Issues=== | ||
Revision as of 16:45, 8 February 2007
The first draft is now posted. Please comment here. Kboone 11:19, 7 February 2007 (CST)
Issues List
I would favor keeping the issues list in the discussion/talk page of the wiki, even if it requires a little cut/paste to convert to the real document. Lkm13 12:43, 7 February 2007 (CST)
Issue Log
Open Issues
One WSDL or two?
HL7 and IHE specifications for Web Services would indicate that the formal contract defining the behavior of the service be described in a single Web Services Definition. However, a WSDL that conforms to HL7 specifications is overly complex for engineering use. I would recommend supplying one WSDL that is the formal contract, and a second WSDL for engineering use, to simplify the creation of client proxies. Kboone 15:45, 8 February 2007 (CST)
Should Accept and Application Acknowledgements be supported?
The web service responds to queries with results. This is a very simple request/response message exchange pattern (MEP), which obviates the need to support application or accept acknowledgements. If the request succeeds, then the response serves as an application level acknowledgement. So, I have decided to not use either of these. Kboone 15:45, 8 February 2007 (CST)
Following the HL7 Shoulds in naming?
The HL7 Web Services profile provides guidance about how to name various components of the service description. No rationale for this guidance is provided, and the names are not easily understood by application developers. Therefore, I have followed the spirit but not the letter for this guidance, using the human readable names derived from the HL7 Ballot materials, instead of the interation identifiers. Note however, that the names of the Elements carried in the soap:Body conform to the "Shall" requirements, in that they do use the HL7 interaction identifiers for the name of the message element. Kboone 15:45, 8 February 2007 (CST)
Number of Actors?
Should there just be a single Clinical Data Source Actor, with optional transactions, or should there be several different kinds of actors? Vitals Data Source, Lab Data Source, Medication and Immunization Data Source, Problems and Allergies Data Source? Increasing the number of actors will increase the number of WSDLs that are needed, but would allow greater flexibility in the profile. A Medication and Immunization Data Source might be integrated with RxHUB or an immunization registry, as well as with an EHR. I think I'm in favor of this approach (but it will mean that there is substantial editing to do). Should the medication data source be separated from the Immunization data source? I think problems and allergies stay together, but am not certain. Kboone 15:45, 8 February 2007 (CST)
Medications and Immunizations?
Do we leave this transaction in Volume 1, and just not implement it this year? The scope issue is that the standards may not support the medication query transactions yet. Kboone 15:45, 8 February 2007 (CST)