ITI and PCC Scope: Difference between revisions

From IHE Wiki
Jump to navigation Jump to search
Kboone (talk | contribs)
mNo edit summary
Kboone (talk | contribs)
mNo edit summary
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
IHE Patient Care Coordination (PCC) domain was established in July 2005 to deal with integration issues that cross providers, patient problems or time. It deals with general clinical care aspects such as document exchange, order processing, and coordination with other specialty domains. PCC also addresses workflows that are common to multiple specialty areas and the integration needs of specialty areas that do not have a separate domain within IHE.  
The IHE IT Infrastructure and Patient Care Coordination domains have what appear to be overlapping scope statements.


The IT Infrastructure Domain supports profiles which supply the necessary infrastructure for sharing healthcare information. An infrastructure interoperability component represents a common IT function that is used as a building block for a variety of use cases... a necessary ingredient, but rarely visible to the end user!! These components may be imbedded in an application, but are often deployed as a shared resource within a RHIO or Health Information Exchange.
;PCC: ''IHE Patient Care Coordination (PCC) domain was established in July 2005 to deal with integration issues that cross providers, patient problems or time. It deals with general clinical care aspects such as document exchange, order processing, and coordination with other specialty domains. PCC also addresses workflows that are common to multiple specialty areas and the integration needs of specialty areas that do not have a separate domain within IHE. ''


Keith: How do we make the dividing line?
;ITI: ''The IT Infrastructure Domain supports profiles which supply the necessary infrastructure for sharing healthcare information. An infrastructure interoperability component represents a common IT function that is used as a building block for a variety of use cases... a necessary ingredient, but rarely visible to the end user!! These components may be imbedded in an application, but are often deployed as a shared resource within a RHIO or Health Information Exchange.''


Bill:  The only concistent words, if it has Clinical Content, PCC, otherwise, ITI.
The question of where a profile proposal falls has come up several times, and the committee chairs met and agreed to several principles which will help to address this issue. These are described below:


Mike:  Agrees, let's try some example.
# When the principle use case is technology driven, it is an ITI Profile.
 
# When the principle use case is clinically driven, it is a PCC Profile.
Manuel: Agrees, has a profile proposal, doesn't know where to put it, e.g., with regard to scheduling.
# When the principle use case is operationally driven, it might be either, or in some cases both, and both committees will need to review to understand where it should land.
 
# When the profile brings in new technology, transports, or messaging systems, ITI will need to be involved.
Bill and Mike disagree on where this might go.
# There may be a need (such as with RFD and QED), to split a proposal up into a part to be addressed by each committeeWhen possible, the ITI portion should be completed first, and the PCC portion second.
 
# If there is a need to expedite a profile that requires participation from both domains, PCC and ITI will appoint co-authors of the profile who will be responsible for addressing nuances between both domains. One and only one committee will be responsible for publishing the profile.
Larry:  In that case, definition of Clinical might be raising some issues.  From a technical perspective, there are non-technical portions of scheduling, needs to have domain expertise.  Clinical to Providers means Patients, singularly or collectively. Tends to agree with Bill that scheduling is not wholly ITI, qualified that technical component does belong in ITI.
# PCC and ITI cochairs will review profile proposals for the other domain, to see if there are areas of overlapThese areas should be identified in advance of the planning meetings.
 
# Each domain will reserve at least one hour in the second half of the planning meeting where PCC and ITI members can call in (if the meetings are not held at the same time and location) to discuss potential areas of overlapAdditional calls will be scheduled if needed after the planning meeting of both domains to finalize decisions.
Bill:  If inside the scheduling discussion, new transports, infrastructure, would be an ITI issue, if existing infrastructure, could stay in PCC.
# Cochairs will continue to coordinate on any profiles where there may be overlap.
 
# PCC and ITI will continue to try to hold meetings at the same time and location to facilitate communication between the two domainsWe will reserve 1-2 hours during those meetings for cross-domain topics.
Larry:  Division might be transport vs. content.
 
Bill:  I think so.
 
Larry:  Counterexample is BPPC.
 
Bill:  Very good point.  Computer science engineering content.
 
Mike:  Back to Appt example, content of a scheduling record, transport which everyone understands, other issues such as processing.
 
Manuel: The way it is written (proposal), it has no clinical content.
 
Keith:  Bill's first observation helps make a good dividing line.
 
Bill: Anything on the operational side, technologists might not know about.
 
Keith: ITI has operational expertise.
 
Bill:  May be a fine line that needs to be discussed.
 
Manuel: Financial would be different.
 
Mike:  There are some that are clearly PCC and ITI.  Up to planning co-chairs to review each.  Some will straddle, and could land in one place or anotherCo-chairs of both committees should coordinate.
 
Karen: Scheduled call on second day of each planning meeting that is a cross domain call to have a call to discuss.
 
Bill:  Towards second half of each planning call, make sure that there is an opportunity for the other committee to call in.
 
Larry: Address dependencies by divvying up appropriately, make sure infrastructure exists.
 
Keith: Kind of like we did with RFD and QED.
 
Bill: Agreed.
 
Mike:  Has PCC and ITI expertise cross committee.
 
Karen: We want to be careful about having JOINT profiles is difficult.  Could be a logistical nightmare.  One domain should own.
 
Keith: I would agree.
 
Bill:  Makes a lot of sense.
 
Larry: If we need to expedite, then we might need to work together.
 
Mike:  If we need to expedite, appoint coeditors, deal with nuances together.
 
Keith: I like that.
 
Bill:  Reponsibility on both sides makes a lot of sense.
 
Karen: Make sure we understand clearly how we are moving forward with theseHard on everyone.
 
Mike:  Support that.

Latest revision as of 15:48, 28 September 2007

The IHE IT Infrastructure and Patient Care Coordination domains have what appear to be overlapping scope statements.

PCC
IHE Patient Care Coordination (PCC) domain was established in July 2005 to deal with integration issues that cross providers, patient problems or time. It deals with general clinical care aspects such as document exchange, order processing, and coordination with other specialty domains. PCC also addresses workflows that are common to multiple specialty areas and the integration needs of specialty areas that do not have a separate domain within IHE.
ITI
The IT Infrastructure Domain supports profiles which supply the necessary infrastructure for sharing healthcare information. An infrastructure interoperability component represents a common IT function that is used as a building block for a variety of use cases... a necessary ingredient, but rarely visible to the end user!! These components may be imbedded in an application, but are often deployed as a shared resource within a RHIO or Health Information Exchange.

The question of where a profile proposal falls has come up several times, and the committee chairs met and agreed to several principles which will help to address this issue. These are described below:

  1. When the principle use case is technology driven, it is an ITI Profile.
  2. When the principle use case is clinically driven, it is a PCC Profile.
  3. When the principle use case is operationally driven, it might be either, or in some cases both, and both committees will need to review to understand where it should land.
  4. When the profile brings in new technology, transports, or messaging systems, ITI will need to be involved.
  5. There may be a need (such as with RFD and QED), to split a proposal up into a part to be addressed by each committee. When possible, the ITI portion should be completed first, and the PCC portion second.
  6. If there is a need to expedite a profile that requires participation from both domains, PCC and ITI will appoint co-authors of the profile who will be responsible for addressing nuances between both domains. One and only one committee will be responsible for publishing the profile.
  7. PCC and ITI cochairs will review profile proposals for the other domain, to see if there are areas of overlap. These areas should be identified in advance of the planning meetings.
  8. Each domain will reserve at least one hour in the second half of the planning meeting where PCC and ITI members can call in (if the meetings are not held at the same time and location) to discuss potential areas of overlap. Additional calls will be scheduled if needed after the planning meeting of both domains to finalize decisions.
  9. Cochairs will continue to coordinate on any profiles where there may be overlap.
  10. PCC and ITI will continue to try to hold meetings at the same time and location to facilitate communication between the two domains. We will reserve 1-2 hours during those meetings for cross-domain topics.