IG Development Working Session

September 4th, 2013

Meeting Etiquette• Remember: If you are not speaking, please keep your

phone on mute• Do not put your phone on hold. If you need to take a call,

hang up and dial in again when finished with your other call o Hold = Elevator Music = frustrated speakers and

participants• This meeting is being recorded

o Another reason to keep your phone on mute when not speaking

• Use the “Chat” feature for questions, comments and items you would like the moderator or other participants to know.o Send comments to All Panelists so they can be

addressed publically in the chat, or discussed in the meeting (as appropriate).

From S&I Framework to Participants:Hi everyone: remember to keep your phone on mute

All Panelists

2

Agenda

Topic Time Allotted

II05 Options DiscussionObjective: come to recommendation for II05

30 minutes

IG Development updates & review 30 minutes

3

II05 Payload – Submit Completed Form Data from EHR System to External Data RepositoryOptions Summary Strengths Weaknesses

XML Value Pairs - XML structure that consists of the name of the data and the response

- A collection of names & values

- Extensible to any form values defined across domains

- Low overhead to implement- Can use LOINC or other established

- Receiver of the data has to be able to interpret the relationship of the pairs

- Though, also the receiver would have the form or knowledge of the form

HL7 CDA Questionnaire Response IG

The purpose of a Questionnaire Response document is to capture the health survey answers or answer sets to questions that have been administered to a patient. Questionnaire Response documents enable the capture of responses for surveying the patient’s perceptions on their health and the impact that any treatments or adjustments to lifestyle have had on their quality of life.

- The Questionnaire Response documents may carry a variety of clinical and non-clinical responses in order to convey back to the healthcare organization the results of a patient questionnaire prescribed according to the Form Definition document

- Can carry structure information of the form

- Can include the CDA Consent Directive IG

- Does not have cross-question relationship linkages

- Metadata is not as comprehensive to carry form data

- Not as extensible

ISO MFI 19763-13 A metadata framework for forms structure & includes all relevant form descriptor & logic information

- Can carry the structure information along with the data itself

- Is being used in other SDC transactions

- Probably not relevant to this transaction(?)- May add overhead to development of the

transaction to be conformant- Does not have an existing implementation

base

HL7 CDA Framework for Questionnaire Assessments

The intent of the current project is two-fold: carry forward the Implementation Guide for CDA Release 2 CDA Framework for Questionnaire Assessments (Universal Realm) and provide specific guidance on implementing the CARE Questionnaire Assessment Forms used in long-term care hospital (LTCH) settings.

- Implemented for CMS- Does have a generic component- The intent of the Questionnaire

Assessment Framework is a generic standard that may be applied to patient questionnaire assessment tools that are used to assess patient medical, cognitive, functional, and health status.

- Developed for custom CMS situation – not as extensible, as for example the MFI

- Does not have cross-question relationship linkages

- Metadata is not as comprehensive to carry form data

- The intent is not to define a standard framework for all assessment types such as an acute hospital admission physical assessment, shift assessments, or discharge assessments.

Custom XML - Can define custom form with sections to support the needs of the transaction

- Low overhead to describe the II05 transaction

- Does meet the need for SDC

- Not a standard – group would not be recommending a standard approach for this transaction

- Receiver of the data has to be able to interpret the data

Other?

II05 Service – Submit Completed Form Data from EHR System to External Data RepositoryOptions Summary Strengths WeaknessesIHE RFD Submit Form

**A package is being published on the for SubmitFormRequest & SubmitFormResponse WSDL**

Target publication is September 13th

Summary:- RFD has a component which allows implementer

to “submit form”- The Submit Form transaction shall carry a

SubmitFormRequest element, with submitted form data as XML child elements of the SubmitFormRequest element. Content profiles may further constrain the content of the SubmitFormRequest element.

Using RFD submit form would require one of the following - The Payload could be structured as a MIME

multipart package OR- Modifications would be required to the

SubmitForm request to allow for explicit slots to serve as place holders for Form data and consent directive, which is a CDA document

- Agnostic of the payload- Separating concerns

architecturally - Used in the rest of the SDC

solution plan- Implementation experience from

an SDC committed member – CDISC & FDA partnership

- Different payloads, have to package together and send them as a single package

- Very little metadata currently in metadata

- Have to open the form before creating the audit form

IHE XDR/XDS - Cross-Enterprise Document Reliable Interchange (XDR) provides document interchange using a reliable messaging system. This permits direct document interchange between EHRs, PHRs, and other healthcare IT systems in the absence of a document sharing infrastructure such as XDS Registry and Repositories.

- Supports multiple packages with metadata as part of the request

- Has a strong metadata set for- Most widely adopted option –

used a part of the NwHIN for document submission

- More robust functionality

- Is a new service component to our other options

- More complex than RFD

Direct Send secure email with payload. The Direct Project establishes standards and documentation to support simple scenarios of pushing data from where it is to where it's needed, in a way that will support more sophisticated interoperability in the future.

- Aligns with MU Data Exchange approach

- Simple from a provider’s perspective to send email

- Security lower in Direct transactions

- Requirement for Direct addresses, linked to 509, manage trust bundles, CA & RA

Custom?

Other solutions?

For discussion with All Hands WG

• Response from the External Data Repository– To this date, a generic “acknowledgement” has been discussed as being in-scope for the SDC Use

Case and IG development– What are the implications on our stakeholders / the Use Case?

• Discuss and add a section in the IG regarding the acknowledgement and error conditions, rather than adding a new transaction

– Error-handling is implementation-specific and complex per the needs of a domain-specific form– Considerations: maintaining data downstream, need for secondary form submission– Pre-Condition for data validation prior to sending?

• Implications on the sender and/or the receiver?• All kinds of combinations for how this could be handled

– A traceable receipt will be invaluable in development as well as production environments

• Discuss use of CDA Consent Directive IG with XML Value Pairs– Would have to be separate items for the transaction to carry that information? Or would they be

carried together as separate pieces under a transaction document• Data Segmentation for Privacy reinforces this use• Consent Directive can include sensitive information as well

– What is the consideration from privacy/security community?

• Transaction Metadata vs. Form Metadata

• IHE Publication Cycle Understanding