Children's Electronic Health Record Format
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 steam. 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 (citation number). In 2001 the ideal qualities of a good pediatric electronic health record were proposed in detail by the American Academy of Pediatrics (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).
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.
- Activity Clearance (6 requirements)
- Growth Data (61 requirements)
- Medication Management (37 requirements)
- Patient Identifier (7 requirements)
- Immunization (48 requirements)
- Quality (5 requirements)
- Registry (14)
- Well Child (83)
- Children with Special Needs (23)
- Patient Portals (11)
- Primary Care Management (31)
- Security and Confidentiality (23)
- Birth Information (66)
- Newborn Screening (16)
- Parents and Guardians and Family (20)
- Prenatal Screening (17)
- Specialized Scales/Scoring (35)
- Child Abuse Reporting (29)
- Child Welfare (20)
- School-based linkages (4)
- Special Terminology and Information (9)
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. 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:
- 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? o 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? o Easy, Moderately Easy, Difficult, Very Difficult • Q5 - If implementation was easy or moderately easy, why? o 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? o 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 o 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 o 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 o 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
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.
Children's EHR Format 2015 Priority List and Recommended Uses
- Institute of Medicine Committee on Quality of Health Care in, A. (2000). 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.
- 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.
- Coiera, E., et al. (2016). "The Unintended Consequences of Health Information Technology Revisited." Yearb Med Inform(1): 163-169.
Submitted by Ben Sanders, April 2018