View source for Provider attributes

Clinical information systems use structured data elements to identify and categorize health care providers as individuals and groups. These '''provider attributes''' describe the personhood, credentials, services, and business practices of providers.  They may also describe providers' relationships to patients, other providers and organizations.  In the United States, incentive programs such as the Medicare and Medicaid Electronic Health Records (EHR) Incentive Programs ([[Meaningful_Use|“Meaningful Use”]]), value-based purchasing and the development of [[Accountable_Care_Organization|accountable care organizations (ACOs)]] have increased the demand for data exchange and clinical decision support based on the identity and attributes of individuals and groups of providers involved with care delivery.  Since the 2010 passage of the [http://www.gpo.gov/fdsys/granule/PLAW-111publ148/PLAW-111publ148/content-detail.html Affordable Care Act], there have been increasing efforts to standardize and integrate provider attributes into clinical information systems, particularly electronic health records and health information exchanges.

==Provider Directory-based Provider Attributes==
EHRs maintain internal tables that describe a range of attributes of the providers who use the EHR, as well as tables for referring and/or external providers that typically contain less information.  Despite the fact that all EHRs have provider tables, they do not necessarily share data structures, transactional standards or provider attribute terminologies. Such differences predict variability in the degree that provider attributes contribute to EHR functionality, such as HL7 messaging to a patient's care team or open searches and scheduling of referrals.  Dependent on EHR-generated patient-provider information, Health Information Exchanges (HIEs) and ACOs have a particular interest in provider directories that contain accurate and up-to-date information about providers in their region.  It is therefore not surprising that efforts to standardize provider attribute data have focused on the development of Provider Directory standards.  Early aims were to provide a gold standard resource to verify provider identities, addresses and to support population health management tools.  In 2011, the Standards and Interoperability (S&I) Framework (a public-private collaboration convened by the ONC Office of Standards & Interoperability) initiated its Provider Directories project which compiled [http://wiki.siframework.org/Provider+Directories+Reference+Materials| a set of reference materials] regarding provider directory standards and implementations.  Two comprehensive Standards Development Organization-approved Provider Directory standards were found to be currently in in existence: the HL7 Version 3 Standard: Healthcare, Community Services and Provider Directory, Release 1 A Service Model Specification and [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf IHE IT Infrastructure Technical Framework Supplement – Healthcare Provider Directory (HPD)], each defining a similar set of provider attributes.

Examples:

''Person''
#Name
#Provider identifiers
#Gender
#Age
#Language(s) spoken

''Training''
#Provider Type
#Specialty*
#Licensing/Accreditation/Certification (LCR)
#LCR expiration and renewal dates

''Work context''
#Health plan network
#Organization(s) (member of)
#Location(s)
#Contact information
#Work schedule
#Accepting new patients

Note that although Specialty is specified by multiple provider directory standards, different provider taxonomies represent variably distinct concepts. See: [[#Challenges]]

==Non-Standard Attributes==
A wide range of provider attributes could be envisioned, though in practice, there are relatively few in common use.

Examples:
* Role
* Hospital privileges
* Clinical service(s) (member of)
* Clinical microsystem(s) (member of)
* Hospital unit(s) (member of)
* Custom specialty taxonomy code(s)

==Clinical Information Systems and Functions that Depend on Provider Attributes==
'''[[Electronic_health_record |Electronic Health Records]]'''
Security settings
: ''Examples: Chart access, order authorization, note attestation, message routing''
'''Referral management'''<br />
'''Care Coordination'''<br />
'''Clinical Decision Support'''<br />
: ''Examples: Information filtering, preference lists
'''Patient-Centric Information Sharing'''
: ''Potential examples: Hospital care apps that show provider photos; patient information trackers with consultant calling cards.[[#References|3]],[[#References|4]]
'''[[Health_Information_Exchange|Health Information Exchange]]'''
'''[[Clinical_Quality_Measures|Hospital Analytics and Quality Measurement]]'''

==Challenges==
Semantic inconsistencies across interfaced clinical information systems and the lack of standards integration are significant barriers to provider attribute-determined functionality.  Admission, Discharge, Transfer (ADT) systems typically house provider attribute data associated with practice management such as the cost center construct(s) assigned to a given provider.  For EHR systems in which the ADT is separate from the rest of the EHR, differing data structures and interface limitations can lead to mismatched provider attribute mapping or the creation of records with values that are out of synch with actual patient-provider-encounter relationships.  An example of the first challenge would be an EHR displaying a general cost center name or academic specialty rather than a clinical service. An example of the latter would be a change in the EHR record of a hospitalized patient that specifies a new attending provider (a role) that is not shared with with the ADT system.

"Specialty" is a particularly complex provider attribute as the term is used in different contexts to represent different concepts. The multiple terminologies associated with specialty reflect this complexity.  For example, in an ADT system, Specialty is likely to represent the business unit or department in which a provider primarily works.  The name of this department is typically derived from the personal training history of the majority of its providers.  It might also represent the Medicare provider type (selected when the provider enrolled as a Medicare provider) or perhaps it is populated with Healthcare Provider Taxonomy Codes sponsored by the National Uniform Claim Committee (NUCC; assigned when applying for a National Provider Identifier (NPI).  Based on these scenarios, a family practitioner who sees a newborn in a hospital nursery will have an ADT-derived specialty listed in association with this care with the following possible values: 
 ''Family Practice'' [organizational/practice group name];
 ''Family Practice'' [Medicare type];
 ''Family Medicine'' [an NUCC taxonomy name]
None of these terms conceptually represent the service rendered by the provider in the nursery, where she intermittently rotates with a pediatric nurse practitioner and three pediatricians to cover routine newborn care in the hospital.  The impact of recording mismatched provider attributes is potentially significant.  Two areas most likely to be affected are Clinical Decision Support (CDS) and data analytics.  

The potential effect on CDS can be seen by imagining CDS tools designed to support newborn care that are triggered on the basis of specialty.  In the example above, all providers with Family Practice/Family Medicine- the majority of whom may not work in the nursery- may be forced to encounter alerts or filtered views. The converse is not desirable either: if specialty-defined CDS is offered only to those with "Pediatrics" as a specialty, the provider who works the least in the nursery setting will be the one who does not have CDS available to her.  The misuse of "Specialty" as a surrogate for the set of providers who rotate in the nursery, essentially neutralizes the attribute as a discriminatory variable to drive this and potentially other instances of CDS in the EHR.  For data analysts, the complexities of data aggregation is also significantly exacerbated when semantic mismatches such as this occur.  Analysts are forced to discover and validate other indicators that correlate with mismatched or unreliable provider attributes, raising costs and threatening the validity of their findings.

One solution to the nursery example would be to define "clinical service(s)" for the work context of the provider, where the attribute is defined as belonging to a set of providers who rotate according to a schedule to provide care to a certain population of patients (e.g., newborns delivered at a defined hospital).  Although clinical service was not specifically adopted as an attribute by the Integrating the Healthcare Enterprise (IHE) Information Technology Infrastructure (ITI) Technical Committee (see: [[#Non-Standard Attributes]]) ''did'' specify that nested "organizational provider" entities could serve the same function.  This offers local organizations the opportunity to define operational units that could serve as targets for CDS and indicators of hospital processes though such nested organizations would not necessarily be meaningful or actionable by a different Clinical Information System.

Maintenance of provider attributes is a pervasive challenge.  Rapid role turnover was cited by the IHE ITI Technical Committee as the basis for excluding "role" as a provider attribute for its trial implementation of its [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf IHE IT Infrastructure Technical Framework Supplement – Healthcare Provider Directory (HPD)].  Although the turnover rate may be on the scale of a few years- as when a provider in a resident role graduates to the level of attending- in a large organization this would represent nearly continuous updates. Rapid turnover in this case should not be confused with the kind of role substitutions that may occur in the course of providing patient care.  For example, a single provider may sequentially play the roles of consulting and attending physician for the same patient within a single hospital admission and may play different roles for different patients concurrently.  This highlights the importance of capturing, in real time, which role a provider is playing for a given patient - it can be difficult to recreate later, especially from aggregated data.  

Outside a Provider Directory, an argument could be made that "Allowable Role(s)" could be a useful provider attribute to constrain the accidental assignment of inappropriate roles (i.e., the assignment of an exclusive specialist as a patient primary care provider).  The roles a given provider may assume are readily known to providers themselves, despite the fact this information tends not to be available in an electronic form as a provider attribute.  Roles are essentially a relational type of another non-standard provider attribute-- hospital privileges.  Privileges specify what procedures a provider may do, where, and under what conditions.  Roles specify patterns of patient care duties and decision authority granted by a local governing body (an incorporated medical staff, in the case of a hospital-affiliated provider).  Role types are also referenced by many non-provider directory standards and the terminology of an "Allowable Role" attribute could be made consistent.  For example, HL7 Clinical Document Architecture, Release 2, specifies roles such as attending physician and primary care provider within its from the Participation class of the HL7 Reference Information Model[[References|2]].  

==Provider Directory and Supporting Standards and Terminologies==

{| class="wikitable"
| '''Standard''' || '''Type'''   || '''Standard Developer''' 
|-
| [http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf IHE IT Infrastructure Technical Framework Supplement – Healthcare Provider Directory (HPD)]  ||  Structural model with content specifications || [http://www.ihe.net Integrating the Healthcare Enterprise] 
|-
| HL7 Version 3 Standard: Healthcare, Community Services and Provider Directory, Release 1 A Service Model Specification || Structural model with content specifications || [http://www.hl7.org HL7 International] 
|-
| [http://www.nucc.org/index.php?option=com_wrapper&view=wrapper&Itemid=126 Health Care Provider Taxonomy] || Content  ||  [http://www.nucc.org/ National Uniform Claim Committee (NUCC)] 
|-
| [http://www.cms.gov/Medicare/Provider-Enrollment-and-Certification/MedicareProviderSupEnroll/Taxonomy.html Crosswalk: Medicare Provider/Supplier to Healthcare Provider Taxonomy] || CMS Center for Program Integrity, Division of Policy & Regulatory Development 
|-
| [http://en.wikipedia.org/wiki/Specialty_(medicine) Specialty medical boards] ||Content || Multiple professional organizations 
|-
| Provider Directory (ASC X12 004050X109)  || Transactional || [http://http://www.x12.org ASRX12 (The Accredited Standards Committee)] 
|-
| Provider Directory (4010X109), Inquiry and Response (4010X185) || Content/Transactional (Implementation Specifications) || [http://www.x12.org ASRX12 (The Accredited Standards Committee)] 
|-
| [http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=51432 Health informatics — Directory services for health care providers, subjects of care, and other entities (ISO/TS 21091)] || Content/Transactional|| I[http://www.iso.org ISO (International Organization for Standardization)] 
|}



==References==
[http://publications.milliman.com/publications/healthreform/pdfs/whose-patient-is-it.pdf] Pantely SA. Whose patient is it?  Patient attribution in ACOs. Milliman Healthcare Reform Briefing Paper. January 2011. Accessed: 10/28/14

[http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1380194/#!po=79.4118] Dolin RH, Alschuler L, Boyer S, Beebe C, Behlen FM, Biron PV, Shabo (Shvo) A. HL7 Clinical Document Architecture, Release 2.  J Am Med Inform Assoc. 2006 Jan-Feb; 13(1): 30–39. Accessed: 10/28/14

[http://techhouse.brown.edu/~dmorris/publications/WilcoxPatientDisplaysCHI2010.pdf] Wilcox L, Morris D, Tan D, Gatewood J. Designing patient-centric information displays for hospitals. Proceedings of the 28th International Conference on Human Factors in Computing Systems (CHI). Atlanta, Georgia, USA: ACM; 2010. Accessed: 10/28/14

[http://www.ncbi.nlm.nih.gov/pubmed/24081019] Collins S, Hurley AC, Chang FY, Illa AR, Benoit A, Laperle S, Dykes PC. Content and functional specifications for a standards-based multidisciplinary rounding tool to maintain continuity across acute and critical care. J Am Med Inform Assoc 2013;0:1–10. doi:10.1136/amiajnl-2013-001949

Submitted by Paul Rosenau

[[Category:BMI512-FALL-14]]