Difference between revisions of "Children's Electronic Health Record Format"

From Clinfowiki
Jump to: navigation, search
(CHIPRA and the model Children's EHR Format of 2009 to 2013)
(Example)
 
(25 intermediate revisions by one user not shown)
Line 1: Line 1:
 +
 +
 
=== Background ===
 
=== Background ===
 
A number of Pediatric EHR functions are unique, such as support for neonatal medicine, congenital syndromes and defects, the use of growth charts, and tracking developmental progress. Many EHR functions such as weight-based dosing and immunization record keeping are used in adult medicine, but without the frequency and importance that they have in pediatrics. On the whole, EHR software development has not emphasized these functions. This may be due in part to the relatively small market share of pediatric medicine, and a slow uptake of EHR by the specialty before the age of Meaningful Use.
 
A number of Pediatric EHR functions are unique, such as support for neonatal medicine, congenital syndromes and defects, the use of growth charts, and tracking developmental progress. Many EHR functions such as weight-based dosing and immunization record keeping are used in adult medicine, but without the frequency and importance that they have in pediatrics. On the whole, EHR software development has not emphasized these functions. This may be due in part to the relatively small market share of pediatric medicine, and a slow uptake of EHR by the specialty before the age of Meaningful Use.
  
In the 1990s the informatics efforts of the American Academy of Pediatrics gathered momentum. Many pediatric implications for the EHR were recognized with reports around patient privacy, adolescent confidentiality, and the patient-centered medical home. Interest in the EHR’s ability to improve patient safety increased with the 2000 publication by the Institute of Medicine titled to To Err Is Human (cite). In 2001 the AAP listed desireable attributes of a highly functional EHR (cite). Spooner later prioritized this list of qualities in 2007 in the paper ''Special requirements of electronic health record systems in pediatrics''.  The 2000’s were marked by studies on the benefits and costs of pediatric clinical information systems such as Computerized Provider Order Entry. In 2005 a study conducted in a pediatric intensive care unit at the Children’s Hospital of Pittsburgh became a flashpoint for attention to the relationship between EHR use and medical errors. Subsequent studies at Seattle Children’s Hospital published in 2006, and in Palo Alto in 2010 put emphasis on implementation itself as a critical factor for the success of EHRs in minimizing medical errors (cite Coiera paper).
+
In the 1990s the informatics efforts of the American Academy of Pediatrics gathered momentum. Many pediatric implications for the EHR were recognized with reports around patient privacy, adolescent confidentiality, and the patient-centered medical home. Interest in the EHR’s ability to improve patient safety increased with the 2000 publication by the Institute of Medicine titled to To Err Is Human (1). In 2001 the AAP listed desireable attributes of a highly functional EHR (2). Spooner later prioritized this list of qualities in 2007 in the paper ''Special requirements of electronic health record systems in pediatrics'' (3).  The 2000’s were marked by studies on the benefits and costs of pediatric clinical information systems such as Computerized Provider Order Entry. In 2005 a study conducted in a pediatric intensive care unit at the Children’s Hospital of Pittsburgh became a flashpoint for attention to the relationship between EHR use and medical errors. Subsequent studies at Seattle Children’s Hospital published in 2006, and in Palo Alto in 2010 put emphasis on implementation itself as a critical factor for the success of EHRs in minimizing medical errors (4).
  
== CHIPRA and the model Children's EHR Format of 2009 to 2013 ==
 
The Children’s Health Insurance Program Reauthorization Act (CHIPRA) was passed by US Congress in 2009 and it included funding for a program to enhance pediatric Electronic Health Records (cite). It would describe pediatric functions in detail for use by EHR application developers. The Agency for Healthcare Research and Quality (AHRQ) and the Centers for Medicare and Medicaid Services (CMS) began by contracting Westat to develop the original list of functions. From 2010 to 2013, contractor Westat created 547 functional requirements in total. They were divided 21 topics, with a number of functional requirements for each topic.
 
  
 +
== CHIPRA and the model Children's EHR Format of 2009 to 2013 ==
 +
The Children’s Health Insurance Program Reauthorization Act (CHIPRA) was passed by US Congress in 2009 and it included funding for a program to enhance pediatric Electronic Health Records (5). It would describe pediatric functions in detail for use by EHR application developers. The Agency for Healthcare Research and Quality (AHRQ) and the Centers for Medicare and Medicaid Services (CMS) began by contracting Westat to develop the original list of functions. From 2010 to 2013, contractor Westat created 547 functional requirements in total. They were divided into 21 topics, with a number of functional requirements for each topic.
  
 
#Activity Clearance (6 requirements)
 
#Activity Clearance (6 requirements)
Line 31: Line 33:
  
  
 +
=== Example Functional Requirements ===
 
Each of these 547 functional requirements described something that this ideal system would do, and each statement included a qualifier adverb SHALL, SHOULD, or MAY to indicate the relative importance of the requirement. For example, functional requirement number 517 under the topic Child Abuse Reporting, is titled <u>Ability to access family history, including all parents</u>:
 
Each of these 547 functional requirements described something that this ideal system would do, and each statement included a qualifier adverb SHALL, SHOULD, or MAY to indicate the relative importance of the requirement. For example, functional requirement number 517 under the topic Child Abuse Reporting, is titled <u>Ability to access family history, including all parents</u>:
  
Line 39: Line 42:
 
::''The system SHOULD allow user selection of appropriate reference standards (e.g. CDC, WHO, Down's, or Turner's Syndrome), display corresponding growth reference percentile curves/calculations, and denote the growth reference used in calculation and display.''
 
::''The system SHOULD allow user selection of appropriate reference standards (e.g. CDC, WHO, Down's, or Turner's Syndrome), display corresponding growth reference percentile curves/calculations, and denote the growth reference used in calculation and display.''
  
From 2012 to 2015, the set of 547 requirements was then distributed to grantees North Carolina and Pennsylvania to evaluate their quality for stakeholders in pediatric medicine. In total, 13 patient care sites and 6 health IT vendors were engaged. In order to assess its presence, value, practicality, and relevance, each requirement came with a set of questions to answer, listed here:
+
 
 +
=== Quality Testing Grants ===
 +
From 2012 to 2015, the set of 547 requirements was then distributed to grantees in North Carolina and Pennsylvania to evaluate their quality for stakeholders in pediatric medicine. In total, 13 patient care sites and 6 health IT vendors were engaged. In order to assess its presence, value, practicality, and relevance, each requirement came with a set of questions to answer, listed here:
  
 
:;Q1 - Please Rate the importance of this requirement:  
 
:;Q1 - Please Rate the importance of this requirement:  
Line 60: Line 65:
 
::Can be implemented immediately, Can be implemented with code change, Can be implemented with workflow change, Can be implemented code and workflow changes, Cannot be implemented external factor, Cannot be implemented – Funding, Cannot be implemented - Personnel Resources, Cannot be implemented – Vendor, Cannot be implemented -, Requires Training
 
::Can be implemented immediately, Can be implemented with code change, Can be implemented with workflow change, Can be implemented code and workflow changes, Cannot be implemented external factor, Cannot be implemented – Funding, Cannot be implemented - Personnel Resources, Cannot be implemented – Vendor, Cannot be implemented -, Requires Training
  
 +
=== Results ===
 +
In total, there were 547 items x 9 questions each, or 4,923 questions, most of which required discussion and consensus by the site’s participants. Grantee sites found the list to be long and some of the requirement language to be difficult to interpret. Prioritization of these items relative to each other was difficult to report and even more difficult to implement. RTI International conducted interviews with participants, and summarized their results as follows (6):
  
In total, there were 547 items x 9 questions each, or 4,923 questions, most of which required discussion and consensus by the site’s participants. Grantee sites found the list to be long and some of the requirement language to be difficult to interpret. Prioritization of these items relative to each other was difficult to report and even more difficult to implement. RTI International conducted interviews with participants, and summarized their results as follows (cite):
+
::''Qualitative analysis pointed to several themes: EHR functionality that is important or necessary, difficulty in interpreting the requirements, missing requirements, and the value of the Format overall. Specific EHR functionality participants found important included customized and integrated percentiles for blood pressure, body mass index (BMI) and growth, integration of existing screening tools and resources, information exchange, integrated reporting and decision support and family linkage. Interpretation was challenged by the language of the requirements and the need for additional resources. Areas for consideration in Format inclusion include social factors and defining medical relevance.''
 +
 
 +
Coincident with the passage of CHIPRA was the passage of the Meaningful Use incentives as part of the American Reinvestment and Recovery Act of 2009. With the large financial incentives awarded to providers who met meaningful use criteria, the EHR industry focused much of its development resources on functions designed to support its clients in doing so. These efforts largely took priority over development of the functions listed in the Children’s EHR Format. In addition, perhaps for some of the reasons grantees mentioned, the length of the list would have made it difficult to prioritize and choose specific items for development. The Format was released to the public in early 2013 on the AHRQ United States Health Information Knowledgebase (USHIK) website (ushik.ahrq.gov/mdr/portals/cehrf?system=cehrf).
  
::Qualitative analysis pointed to several themes: EHR functionality that is important or necessary, difficulty in interpreting the requirements, missing requirements, and the value of the Format overall. Specific EHR functionality participants found important included customized and integrated percentiles for blood pressure, body mass index (BMI) and growth, integration of existing screening tools and resources, information exchange, integrated reporting and decision support and family linkage. Interpretation was challenged by the language of the requirements and the need for additional resources. Areas for consideration in Format inclusion include social factors and defining medical relevance.
 
  
Coincident with the passage of CHIPRA was the passage of the Meaningful Use incentives as part of the American Reinvestment and Recovery Act of 2009. With the large financial incentives awarded to providers who met meaningful use criteria, the EHR industry focused much of its development resources on functions designed to support its clients in doing so. These efforts largely took priority over development of the functions listed in the Children’s EHR Format. In addition, perhaps for some of the reasons grantees mentioned, the length of the list would have made it difficult to prioritize and choose specific items for development.
 
  
 
== Children's EHR Format 2015 Priority List and Recommended Uses ==
 
== Children's EHR Format 2015 Priority List and Recommended Uses ==
 +
In order to promote use of the format and make it more accessible to developers and other stakeholders, the AHRQ enhanced the 2013 format with a high priority selection of it. The new 2015 Priority List contains 47 functionalities with the following titles (7,8).
  
 +
:#Link maternal and birth data to child health record
 +
:#Record all vital signs and growth parameters precisely
 +
:#Provide unit conversions calculation and display during data entry and display
 +
:#Screening tool status
 +
:#Closest available standardized dose
 +
:#Ability to access family history, including all guardians and caregivers
 +
:#Incorporate and adhere to local and national laws in regards to patient EHR access
 +
:#Ability to document parental (guardian) notification or permission
 +
:#Allow unknown patient sex
 +
:#Order blood products in pediatric units
 +
:#Synchronize immunization histories with registry
 +
:#Compute weight-based drug dosage
 +
:#Alert based on age-specific norms
 +
:#Flag special healthcare needs
 +
:#Newborn dried blood spot collection time and state
 +
:#Record parental notification of newborn screening diagnosis
 +
:#Record diagnoses on patient problem summary list
 +
:#Support appropriate newborn screening and follow-up
 +
:#Record Gestational Age Assessment and Persist in the EHR
 +
:#Physical exam screening results
 +
:#Associate mother's demographics with newborn
 +
:#DME and nursing needs
 +
:#Support pre-visit history/screening/prevention forms
 +
:#Track incomplete preventive care opportunities
 +
:#Age-specific decision support
 +
:#Transferrable access authority
 +
:#Produce completed forms from EHR data
 +
:#Use established immunization messaging standards
 +
:#Age-based educational cues
 +
:#Document decision-making authority of patient representative
 +
:#Adoption history
 +
:#Authorized non-clinician viewers of EHR data
 +
:#Placement setting in out-of-home care
 +
:#Alert for foster care without Medicaid
 +
:#Rounding for administrable doses
 +
:#Re-prescribe medications
 +
:#Age- and weight-specific single dose range checking
 +
:#Separate consent, assent and permission
 +
:#Problem-specific age of consent
 +
:#Age of emancipation
 +
:#Segmented access to information
 +
:#Support growth charts for children
 +
:#Scales and Scoring
 +
:#Use biometric-specific norms for growth curves
 +
:#Provide alerts for out-of-range biometric data
 +
:#Import data from pre-visit history/screening/prevention forms
 +
:#Identify incomplete preventive care opportunities
 +
 +
 +
=== Example of a 2015 Priority Functional Requirement ===
 +
A specific function statement accompanies each of these 47 functionalities, and a description providing context has been added. All statements include the adverb SHALL instead of SHOULD or MAY. For example, Requirement number 2011 titled <u>Synchronize immunization histories with registry</u>:
 +
 +
:'''Req ID'''    Req-2011
 +
 +
:'''Title''' Synchronize immunization histories with registry
 +
 +
:'''Release Package''' 2015 Priority List
 +
 +
:'''Format Related Requirements''' Req-611: Synchronize immunization histories with registry
 +
 +
:'''Description''' The system shall support updating and reconciling a child's immunization record with information received from Immunization Information Systems (IISs) or other Health Information Exchanges (HIEs).
 +
 +
:'''Topic Area(s)''' Immunizations, Registry Linkages
 +
 +
:'''Requirement Type''' Normative Statement
 +
 +
:'''Shall/Should/May''' SHALL
 +
 +
:'''Critical/Core''' Yes
 +
 +
:'''Status''' Released
 +
 +
:'''Implementation Notes'''
 +
::There are important differences between medication reconciliation and immunization reconciliation that vendors should consider when designing an EHR for children.  • Medication reconciliation focuses on a single correct list of all current active medications, and immunization reconciliation focuses on the complete history of all immunizations that a child has received. • Medication reconciliation data usually comes from the original electronic prescription rather than manual transcription of data on forms or into the EHR; hence medication data are less prone to data entry errors. • EHR systems do not have permission to change data in an IIS that they receive by retrieving an immunization history, but they can submit new immunizations including ones present in the practice EHR data. With some IIS, an EHR can request changes in the IIS data, but there will be times when an EHR will want to maintain a different immunization history from the one in the IIS and use the EHR data for decision support if the provider believes that the IIS data are incorrect. • It is important to distinguish between a newly administered immunization, an immunization administered in the practice previously and on file in the EHR, data in the EHR obtained by transfer of records from another practice, data in the EHR obtained from another IIS, and data in the EHR obtained by history...    ''[original text is truncated here for space]''
 +
 +
=== Recommended Uses of the 2015 Priority List ===
 +
This shorter list was also accompanied by a list of 16 Recommended Uses by stakeholders.
 +
 +
:'''Direct Uses (Improvements in Software or Implementation)'''
 +
:Providers and associated staff who use and select EHRs
 +
::1. Inform RFP/RFI development to ensure needed EHR functionality for the care of children
 +
::2. Support more productive vendor and/or provider discussions and expectation setting
 +
::3. Support ongoing improvements in the use of the EHR by providers and practice staff
 +
:Software developers
 +
::4. Improve the design and product road map for an EHR used in the care of children
 +
::5. Support better interoperability and integration within and between systems
 +
 +
:'''Indirect Uses (Improvements Built on Direct Uses)'''
 +
:User advocacy groups, EHR system evaluators, and end users
 +
::6. Surface opportunities to improve workflow and other aspects of EHR use
 +
:School district providers and medical administrators
 +
::7. Share information with school districts
 +
:CMS, State Medicaid, and CHIP, and private payers and policymakers
 +
::8. Improve the alignment of EHR functionality with emerging financial policy
 +
:SDO, certification bodies, and professional associations 9. Support standards development
 +
::10. Identify functionalities for certifying health IT product functionality
 +
:State or county health and human services agencies
 +
::11. Establish expectations for electronic data capture and retrieval
 +
::12. Coordination of care, specifically children with special health care needs
 +
:Public health agencies
 +
::13. Support the public health functions of population health assessment, public health policy development, and assurance of public health policy compliance
 +
:Administrators, care coordinators, and health plans
 +
::14. Improve reporting around population health management
 +
:Quality reporting measure developers
 +
::15. Support for eMeasure development and specification
 +
:Pharmacists, pharmacy staff, and pharmacy management system vendors
 +
::16. Increase communication with pharmacists to support safer medication use
  
 
=== References ===
 
=== References ===
#Institute of Medicine Committee on Quality of Health Care in, A. (2000). Washington (DC), National Academies Press (US)
+
#Institute of Medicine Committee on Quality of Health Care in America. (2000). "To Err is Human: Building a Safer Health System" Washington (DC), National Academies Press (US)
#(2001). "American Academy of Pediatrics: Task Force on Medical Informatics. Special requirements for electronic medical record systems in pediatrics." PEDIATRICS 108(2): 513-515.
+
#American Academy of Pediatrics: Task Force on Medical Informatics (2001). "Special requirements for electronic medical record systems in pediatrics." PEDIATRICS 108(2): 513-515.
#Spooner, S. A. and A. A. o. P. Council on Clinical Information Technology (2007). "Special requirements of electronic health record systems in pediatrics." PEDIATRICS 119(3): 631-637.
+
#Spooner, S. A. and AAP Council on Clinical Information Technology (2007). "Special requirements of electronic health record systems in pediatrics." PEDIATRICS 119(3): 631-637.
 
#Coiera, E., et al. (2016). "The Unintended Consequences of Health Information Technology Revisited." Yearb Med Inform(1): 163-169.
 
#Coiera, E., et al. (2016). "The Unintended Consequences of Health Information Technology Revisited." Yearb Med Inform(1): 163-169.
 +
#Children's Health Insurance Program Reauthorization Act of 2009. Washington, DC; 2009 (www.gpo.gov/fdsys/pkg/PLAW-111publ3/html/PLAW-111publ3.htm).
 +
#Wald JS, Haque SN, Ebron SC. Children’s EHR Format Enhancement: Report on Implementation Experiences in North Carolina and Pennsylvania. (Prepared by the RTI International under Contract No. HHSA 290-2009-00021-I). AHRQ Publication No.15-0028-EF. Rockville, MD: Agency for Healthcare Research and Quality. March 2015.
 +
#Wald JS, R. S., Webb JR., Haque S, et al. (2015). Children’s EHR Format Enhancement: Final Recommendation Report. Rockville, MD.
 +
#Wald, J. S., et al. (2018). "Enhancing Health IT Functionality for Children: The 2015 Children's EHR Format." PEDIATRICS 141(4).
  
  
  
 
[[Category:BMI512-SPRING-18]]
 
[[Category:BMI512-SPRING-18]]
 +
 +
  
 
Submitted by Ben Sanders, April 2018
 
Submitted by Ben Sanders, April 2018

Latest revision as of 17:36, 2 May 2018


Background

A number of Pediatric EHR functions are unique, such as support for neonatal medicine, congenital syndromes and defects, the use of growth charts, and tracking developmental progress. Many EHR functions such as weight-based dosing and immunization record keeping are used in adult medicine, but without the frequency and importance that they have in pediatrics. On the whole, EHR software development has not emphasized these functions. This may be due in part to the relatively small market share of pediatric medicine, and a slow uptake of EHR by the specialty before the age of Meaningful Use.

In the 1990s the informatics efforts of the American Academy of Pediatrics gathered momentum. Many pediatric implications for the EHR were recognized with reports around patient privacy, adolescent confidentiality, and the patient-centered medical home. Interest in the EHR’s ability to improve patient safety increased with the 2000 publication by the Institute of Medicine titled to To Err Is Human (1). In 2001 the AAP listed desireable attributes of a highly functional EHR (2). Spooner later prioritized this list of qualities in 2007 in the paper Special requirements of electronic health record systems in pediatrics (3). The 2000’s were marked by studies on the benefits and costs of pediatric clinical information systems such as Computerized Provider Order Entry. In 2005 a study conducted in a pediatric intensive care unit at the Children’s Hospital of Pittsburgh became a flashpoint for attention to the relationship between EHR use and medical errors. Subsequent studies at Seattle Children’s Hospital published in 2006, and in Palo Alto in 2010 put emphasis on implementation itself as a critical factor for the success of EHRs in minimizing medical errors (4).


CHIPRA and the model Children's EHR Format of 2009 to 2013

The Children’s Health Insurance Program Reauthorization Act (CHIPRA) was passed by US Congress in 2009 and it included funding for a program to enhance pediatric Electronic Health Records (5). It would describe pediatric functions in detail for use by EHR application developers. The Agency for Healthcare Research and Quality (AHRQ) and the Centers for Medicare and Medicaid Services (CMS) began by contracting Westat to develop the original list of functions. From 2010 to 2013, contractor Westat created 547 functional requirements in total. They were divided into 21 topics, with a number of functional requirements for each topic.

  1. Activity Clearance (6 requirements)
  2. Growth Data (61 requirements)
  3. Medication Management (37 requirements)
  4. Patient Identifier (7 requirements)
  5. Immunization (48 requirements)
  6. Quality (5 requirements)
  7. Registry (14)
  8. Well Child (83)
  9. Children with Special Needs (23)
  10. Patient Portals (11)
  11. Primary Care Management (31)
  12. Security and Confidentiality (23)
  13. Birth Information (66)
  14. Newborn Screening (16)
  15. Parents and Guardians and Family (20)
  16. Prenatal Screening (17)
  17. Specialized Scales/Scoring (35)
  18. Child Abuse Reporting (29)
  19. Child Welfare (20)
  20. School-based linkages (4)
  21. Special Terminology and Information (9)


Example Functional Requirements

Each of these 547 functional requirements described something that this ideal system would do, and each statement included a qualifier adverb SHALL, SHOULD, or MAY to indicate the relative importance of the requirement. For example, functional requirement number 517 under the topic Child Abuse Reporting, is titled Ability to access family history, including all parents:

The system SHALL provide the ability to access family history, including all parents (biological, foster, adoptive, guardian, surrogate, and custody), siblings, and case workers; with contact information for each.

As another example, requirement number 116 is titled Ability to select reference standards and falls under the topic Growth Data:

The system SHOULD allow user selection of appropriate reference standards (e.g. CDC, WHO, Down's, or Turner's Syndrome), display corresponding growth reference percentile curves/calculations, and denote the growth reference used in calculation and display.


Quality Testing Grants

From 2012 to 2015, the set of 547 requirements was then distributed to grantees in North Carolina and Pennsylvania to evaluate their quality for stakeholders in pediatric medicine. In total, 13 patient care sites and 6 health IT vendors were engaged. In order to assess its presence, value, practicality, and relevance, each requirement came with a set of questions to answer, listed here:

Q1 - Please Rate the importance of this requirement
Of Little Importance, Moderately Important, Important, Highly Important
Q2 - Check this box if the requirement was implemented
Implemented (grant), Previously Implemented, Coming Future Release, Not Implemented, Not Addressing at this Time, Part of Package (not in use)
Q3 - If the requirement was not implemented, why?
Insufficient Funding, Resources and Skills Unavailable, Lack of Stakeholder/Physician Support , Vendor/Partner unable to Deliver, Prohibited by Policy/Security Guideline, Discrete Data Unavailable, Unfeasible Scope (Software Changes and Vendor Enhancement), Unfeasible Scope (Integration and Interoperability)
Q4 - If Implemented, rate the ease of implementation?
Easy, Moderately Easy, Difficult, Very Difficult
Q5 - If implementation was easy or moderately easy, why?
Sufficient Funding, Ample Resources and Skills, Strong Stakeholder/Physician Support, Timely Vendor/Partner Delivery, Permissible Per Policy, Discrete Data Immediately Available, Routine Scope (Software Changes and Vendor Enhancement), Routine Scope (Integration and Interoperability)
Q6 - If implementation was Difficult or Very Difficult, why?
Constrained by Funding, Limited Resources and Skills, Lack of Stakeholder/Physian Support, Vendor/Partner Delivery Challenges, Constrained by Policy/Security Guidelines, Discrete Data not Immediately Available, Complex Scope (Software Changes and Vendor Enhancement), Complex Scope (Integration and Interoperability)
Q7 - Health System_EHR Status
EHR does Not Have Capability, EHR has capability and Feature in Use, EHR has capability and feature not in use, EHR has partial capability feature in use, EHR has partial capability feature not in use
Q8 - Complexity
Refine existing workflow, Define new workflow, Simple development and workflow, Moderate development and workflow, Complex development and workflow, Dependant on non-existent external data
Q9 - Ability to Implement
Can be implemented immediately, Can be implemented with code change, Can be implemented with workflow change, Can be implemented code and workflow changes, Cannot be implemented external factor, Cannot be implemented – Funding, Cannot be implemented - Personnel Resources, Cannot be implemented – Vendor, Cannot be implemented -, Requires Training

Results

In total, there were 547 items x 9 questions each, or 4,923 questions, most of which required discussion and consensus by the site’s participants. Grantee sites found the list to be long and some of the requirement language to be difficult to interpret. Prioritization of these items relative to each other was difficult to report and even more difficult to implement. RTI International conducted interviews with participants, and summarized their results as follows (6):

Qualitative analysis pointed to several themes: EHR functionality that is important or necessary, difficulty in interpreting the requirements, missing requirements, and the value of the Format overall. Specific EHR functionality participants found important included customized and integrated percentiles for blood pressure, body mass index (BMI) and growth, integration of existing screening tools and resources, information exchange, integrated reporting and decision support and family linkage. Interpretation was challenged by the language of the requirements and the need for additional resources. Areas for consideration in Format inclusion include social factors and defining medical relevance.

Coincident with the passage of CHIPRA was the passage of the Meaningful Use incentives as part of the American Reinvestment and Recovery Act of 2009. With the large financial incentives awarded to providers who met meaningful use criteria, the EHR industry focused much of its development resources on functions designed to support its clients in doing so. These efforts largely took priority over development of the functions listed in the Children’s EHR Format. In addition, perhaps for some of the reasons grantees mentioned, the length of the list would have made it difficult to prioritize and choose specific items for development. The Format was released to the public in early 2013 on the AHRQ United States Health Information Knowledgebase (USHIK) website (ushik.ahrq.gov/mdr/portals/cehrf?system=cehrf).


Children's EHR Format 2015 Priority List and Recommended Uses

In order to promote use of the format and make it more accessible to developers and other stakeholders, the AHRQ enhanced the 2013 format with a high priority selection of it. The new 2015 Priority List contains 47 functionalities with the following titles (7,8).

  1. Link maternal and birth data to child health record
  2. Record all vital signs and growth parameters precisely
  3. Provide unit conversions calculation and display during data entry and display
  4. Screening tool status
  5. Closest available standardized dose
  6. Ability to access family history, including all guardians and caregivers
  7. Incorporate and adhere to local and national laws in regards to patient EHR access
  8. Ability to document parental (guardian) notification or permission
  9. Allow unknown patient sex
  10. Order blood products in pediatric units
  11. Synchronize immunization histories with registry
  12. Compute weight-based drug dosage
  13. Alert based on age-specific norms
  14. Flag special healthcare needs
  15. Newborn dried blood spot collection time and state
  16. Record parental notification of newborn screening diagnosis
  17. Record diagnoses on patient problem summary list
  18. Support appropriate newborn screening and follow-up
  19. Record Gestational Age Assessment and Persist in the EHR
  20. Physical exam screening results
  21. Associate mother's demographics with newborn
  22. DME and nursing needs
  23. Support pre-visit history/screening/prevention forms
  24. Track incomplete preventive care opportunities
  25. Age-specific decision support
  26. Transferrable access authority
  27. Produce completed forms from EHR data
  28. Use established immunization messaging standards
  29. Age-based educational cues
  30. Document decision-making authority of patient representative
  31. Adoption history
  32. Authorized non-clinician viewers of EHR data
  33. Placement setting in out-of-home care
  34. Alert for foster care without Medicaid
  35. Rounding for administrable doses
  36. Re-prescribe medications
  37. Age- and weight-specific single dose range checking
  38. Separate consent, assent and permission
  39. Problem-specific age of consent
  40. Age of emancipation
  41. Segmented access to information
  42. Support growth charts for children
  43. Scales and Scoring
  44. Use biometric-specific norms for growth curves
  45. Provide alerts for out-of-range biometric data
  46. Import data from pre-visit history/screening/prevention forms
  47. Identify incomplete preventive care opportunities


Example of a 2015 Priority Functional Requirement

A specific function statement accompanies each of these 47 functionalities, and a description providing context has been added. All statements include the adverb SHALL instead of SHOULD or MAY. For example, Requirement number 2011 titled Synchronize immunization histories with registry:

Req ID Req-2011
Title Synchronize immunization histories with registry
Release Package 2015 Priority List
Format Related Requirements Req-611: Synchronize immunization histories with registry
Description The system shall support updating and reconciling a child's immunization record with information received from Immunization Information Systems (IISs) or other Health Information Exchanges (HIEs).
Topic Area(s) Immunizations, Registry Linkages
Requirement Type Normative Statement
Shall/Should/May SHALL
Critical/Core Yes
Status Released
Implementation Notes
There are important differences between medication reconciliation and immunization reconciliation that vendors should consider when designing an EHR for children. • Medication reconciliation focuses on a single correct list of all current active medications, and immunization reconciliation focuses on the complete history of all immunizations that a child has received. • Medication reconciliation data usually comes from the original electronic prescription rather than manual transcription of data on forms or into the EHR; hence medication data are less prone to data entry errors. • EHR systems do not have permission to change data in an IIS that they receive by retrieving an immunization history, but they can submit new immunizations including ones present in the practice EHR data. With some IIS, an EHR can request changes in the IIS data, but there will be times when an EHR will want to maintain a different immunization history from the one in the IIS and use the EHR data for decision support if the provider believes that the IIS data are incorrect. • It is important to distinguish between a newly administered immunization, an immunization administered in the practice previously and on file in the EHR, data in the EHR obtained by transfer of records from another practice, data in the EHR obtained from another IIS, and data in the EHR obtained by history... [original text is truncated here for space]

Recommended Uses of the 2015 Priority List

This shorter list was also accompanied by a list of 16 Recommended Uses by stakeholders.

Direct Uses (Improvements in Software or Implementation)
Providers and associated staff who use and select EHRs
1. Inform RFP/RFI development to ensure needed EHR functionality for the care of children
2. Support more productive vendor and/or provider discussions and expectation setting
3. Support ongoing improvements in the use of the EHR by providers and practice staff
Software developers
4. Improve the design and product road map for an EHR used in the care of children
5. Support better interoperability and integration within and between systems
Indirect Uses (Improvements Built on Direct Uses)
User advocacy groups, EHR system evaluators, and end users
6. Surface opportunities to improve workflow and other aspects of EHR use
School district providers and medical administrators
7. Share information with school districts
CMS, State Medicaid, and CHIP, and private payers and policymakers
8. Improve the alignment of EHR functionality with emerging financial policy
SDO, certification bodies, and professional associations 9. Support standards development
10. Identify functionalities for certifying health IT product functionality
State or county health and human services agencies
11. Establish expectations for electronic data capture and retrieval
12. Coordination of care, specifically children with special health care needs
Public health agencies
13. Support the public health functions of population health assessment, public health policy development, and assurance of public health policy compliance
Administrators, care coordinators, and health plans
14. Improve reporting around population health management
Quality reporting measure developers
15. Support for eMeasure development and specification
Pharmacists, pharmacy staff, and pharmacy management system vendors
16. Increase communication with pharmacists to support safer medication use

References

  1. Institute of Medicine Committee on Quality of Health Care in America. (2000). "To Err is Human: Building a Safer Health System" Washington (DC), National Academies Press (US)
  2. American Academy of Pediatrics: Task Force on Medical Informatics (2001). "Special requirements for electronic medical record systems in pediatrics." PEDIATRICS 108(2): 513-515.
  3. Spooner, S. A. and AAP Council on Clinical Information Technology (2007). "Special requirements of electronic health record systems in pediatrics." PEDIATRICS 119(3): 631-637.
  4. Coiera, E., et al. (2016). "The Unintended Consequences of Health Information Technology Revisited." Yearb Med Inform(1): 163-169.
  5. Children's Health Insurance Program Reauthorization Act of 2009. Washington, DC; 2009 (www.gpo.gov/fdsys/pkg/PLAW-111publ3/html/PLAW-111publ3.htm).
  6. Wald JS, Haque SN, Ebron SC. Children’s EHR Format Enhancement: Report on Implementation Experiences in North Carolina and Pennsylvania. (Prepared by the RTI International under Contract No. HHSA 290-2009-00021-I). AHRQ Publication No.15-0028-EF. Rockville, MD: Agency for Healthcare Research and Quality. March 2015.
  7. Wald JS, R. S., Webb JR., Haque S, et al. (2015). Children’s EHR Format Enhancement: Final Recommendation Report. Rockville, MD.
  8. Wald, J. S., et al. (2018). "Enhancing Health IT Functionality for Children: The 2015 Children's EHR Format." PEDIATRICS 141(4).


Submitted by Ben Sanders, April 2018