Talk:Query for Existing Data

From IHE Wiki
Jump to: navigation, search

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

Service Discovery

This profile accentuates the need for an IHE ITI profile to discover IHE web service implementations.

Kboone 12:26, 22 May 2007 (CDT)

Closed 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)

There are seperate Data Repository actors. Problems and allergies will stay together.

Kboone 12:26, 22 May 2007 (CDT)

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)

We will implement medications and immunizations transactions this year, as the standards are available.

Kboone 12:26, 22 May 2007 (CDT)

CDISC CDASH activities

The CDISC CDASH project is explained in the attached Powerpoint file. Media:CDASH_15Mar07_RF.ppt

CDASH draws on data definitions in SDTM, the CDISC standard for data submission to FDA.

HL7 Stuff

Generic Patient-Related Pharmacy Query Topic

Meds
PORX_RM060160UV, PORX_RM060180UV
Observations
Common Observations

Labs*, Vitals

Problems, Allergies
Care Record Query

Problems, Risk Factors, Allergies

TCON March 23

Attendance
Keith Boone, Larry McKnight, Vassil Peychev

Status of Care Provision Domain Status: Care Structures, Care Record, Care Record Query, and Professional Service, and Common Observations went DSTU. Content in May 2007 Ballot is what has passed as DSTU, but it is not clear what happened with Common Observations.

We want to use pertinentInformation3 to capture this query.

Larry will try to get us time on Patient Care Agenda.

We had a lot of discussion about the synchronization with HL7 standards work in other topic areas, e.g. Allergies/Intolerances, Problems topic, et cetera.

One issue with using Care Record Profile Query is that while the responses are Care Statements, eventually they should be care statements that conform to specifications in the Allergies/Intollerance or Problems topic.

Larry is concerned that if we use Care Record Profile Query, then divergence may occur in the subtopics, which would result in us having to change the profile in later years when the DSTU becomes final and incorporates the work of these other topics.

My concern is that this specic query seems to meet most of the needs for QED, in a way that provides for concistent responses with a clear coorespondence to the work that we've already done, and that the topic specific queries do not accomplish these objectives because the results are:

  1. Found in different places in the results being returned,
  2. Are further from what we've already done,
  3. Are less uniform overall.

We think that using Care Record Profile Query is OK, but we'll have to be careful, and try to harmonize with current work, and be aware that this may result in change later on.

Kboone 13:27, 23 March 2007 (CDT)

TCON March 30

Agenda:

  1. HL7 Patient Care Status Update
    Larry submitted the DSTU work from HL7 Patient Care. It seems like this should be in the HL7 2006 Edition.
  2. HITSP Use Case Drivers for QED
    There may be some use for this profile in the AHIC use cases for HITSP.
    1. Consumer Empowerment
      Immunization Registries.
    2. Medication Reconcilliation
  3. Technical Framework Issues
    1. Year 2 Final Text
      There may be a way to make use of existing work in the TF in support of this profile. Keith needs to play with the wiki some more.
    2. Support for Wiki Development
  4. CDASH
    How do we get to the point where this is usable by pharma. TCON with Landen next Monday at 3:30pm

May 21 Edits

Kboone 11:50, 21 May 2007 (CDT)

The CDISC CDASH project is explained in the attached Powerpoint file. Media:CDASH_15Mar07_RF.ppt

 CDASH draws on data definitions in SDTM, the CDISC standard for data submission to FDA.