PCC Minutes - November 7th-8th

Tuesday: Reviewed agenda, reordered some items to allow for participation in ITI and PCC activities.

Quick (10 Minute) overviews of Profile Proposals

Focused Care Management

Focused Care Management was reviewed. Key talking points:

1. Support for an Alternate Care Provider to Review and Add Information
2. Needs also to address issues in Quality, Aggregated Care Data vs. Individual. Many quality measures are really dealling with care of patients with Chronic conditions.
3. Profile appears to be a Framework for support of CDM/Public Health Registries
4. Need to address support for Immunization and Cancer Registry Data
5. Req't from Canada to support V3, but in US, installed base is V2.x

Standards:

• HL7 V2.X - NAACCR, CDC 2.3.1 Registry
• HL7 V3 Immunization
• HSSP
• QRDA

Need to support identification of data elements (quality, numerator and demonitor commponents)

Need a way to define the data set, query for that data, accept unsolicited data updates, and support decision support with same.

Patient Care Workflow

Key Concept is Medical Home, somebody knows and manages "EVERYTHING" about the patient. Documents or metadata needs to be communicated to more than one provider.

Embed in CDA Header key data, e.g., identify medical home for patient. This could be communciations address.

Possible use of NAV and PWP was discussed.

Need to support ad-hoc, provider to provider communcation. Need to be able to identify provider, and technology resources used to communicate.

There is a triple, Patient, Provider, and Organization through which they have relationship.

Key elements that identify patient are MRN and Organization. Key elements that identify target for communication are either provider/organization, or in context of a patient, role, patient, organization.

Need some sort of telecom address to handle this.

Thought: ######@ihe.net

Discussion with ITI resulted in loud NO! General discussion: Sounds simple, but when you dig into it, it isn't. Issues not explained. Need to follow up.

Mention of ISO Registry standard, may need to look into this.

RFD/QED Discussion

RFD has changed, Form Filler now sends "Chunk of XML Context" (Blob) to forms manager to support FM selection of form to fill. Needs to have a content profile.

Concern raised that "Chunk of XML Context" will result in to many content profiles. Authors seemed to think it needed only a few, PCC consensus was that it needed many.

After two days of discussion, end result is that we are looking at different levels of interoperability.

1. With "a few" content profiles, EMR can fill in some, but not all fields on a form. Will still require copy and paste, even for data that the EMR might be able to obtain for prepopulation. For Clinical Trials, this is "Good enough", and much better than what they have.

2. For other users, this is insufficient. A concern was raised that profile does not meet all its intended uses, and that "Good enough" for clinical trials is not good enough for other purposes, that it would be hard to sell this profile in spaces where the end-user knows that the EMR knows the data, and integration profile makes it look as if the EMR is unaware.

Bridging between Standatds

+------+ +------+ |NEMSIS| |HL7 V2| | |----| or V3| +------+ +------+

+------+ +------+ |CDISC | |HL7 V2| | |----| or V3| +------+ +------+

Both need a "Bridge", HL7/RCRIM has one that is a work in progress. Could use a gateway between these.

CDASH is a tightly defined set of data elements that could be mapped to PCC-TF.

Family History Exchange

Content profile, request for FH for Son goes to father's PHR. Father's PHR returns submission set containing: Consent to use information to son, and Son's family history (so that all PHI exchanged now "belongs" to son).

Key Data elements: Problems -- Inherited Diseases Race and Ethnicity? Age at Onset/Diagnosis Age at Death Cause of Death Social Issues: Alchohol, Drug Abuse -- CONSENT! Exposures Relation to Patient Psychiatric Issues -- CONSENT!

Most of this content is already in the TF, this would be a content profile explaining how to exchange this content in a document.

Critical Results

Another form of Provider - Provider Communication

Key Distinction: Critical Result, vs. Important Result. Vocabulary: Urgent, Emergent, Not Urgent Where we fail is "Not Urgent"

Precondition: In an order, include communication addresses for distribution of critical results.

Need to support legal record of attempted contact and success or failure. Q to ITI: Could Audit log be used for this. A: No.

PWP and ECON might be useful. ECON would be translated as list of Emergency Contacts wher the types of information returned could be providers who need to recieve Urgent/Emergent/Non-Urgent results.

Have more than one provider to recieve a critical result is useful.

Note: Level of urgency, could potentially influense repsonse of registry for ECON query.

Concern about how the registry would be updated, why is this not included in ADT feed, which has provider relationships already?

PIX/PDQ/PWP/ECON, all mentioned for this. Add to ITI discussion topic.

(After ITI Discussion: Consensus reached that trying to do a profile that has dependencies on incomplete ITI profile would not work, need to deal with this as a white paper: How to use ITI profiles to support this capability. Draft Paul Nagy, Kevin O'Donnell to help with this paper in PCC.