United States Health Information Knowledgebase

 

Glossary


Field 2013 Format 2015 Priority List Description
Achievability Yes No The Achievability field represents a scale used to roughly estimate the degree of achievability of a requirement in an EHR system. For example, some of the more "aspirational" requirements in the Format would be quite difficult for a developer to implement because of external factors, such as nonexistent standards or evolving science. These may be "low" in the Achievability field.
Additional Information Yes No This field indicates that there is additional information describing the need for the requirement or how the functionality might be used in practice.
Comments Yes No General comments related to the requirement.
Critical/Core Yes Yes Requirements with this attribute were identified as the most critical requirements to the functioning of an EHR system used in general pediatric practice, including the inpatient setting. These requirements were identified by a team of four subject matter experts limited to about thirty requirements in total. Core requirements were selected for use in Format validation activities.
Description Yes Yes The description is used to provide an exact and well defined statement of what the requirement is supposed to achieve. Description information will differ depending upon the type of requirement being described, specifics of which are further related in the Requirement Type definition.
Function Statement Yes No This type of requirement is always a child of a Header and describes a specific process or action performed by the system. Functions are parents of sets of Normative Statements. No items are labeled "Function Statement" in the 2015 Priority List items.
Header Yes No This term is used to denote a general process to be performed by the system and frequently encapsulates a set of Sub-Headers, Functions, and Normative Statements that make-up the overall requirements tree. No items are labeled Header in the 2015 Priority List items.
Implementation Notes No Yes This field provides detailed supplemental information regarding the implementation of a given requirement from the 2015 Priority List. This field is empty for the 2013 Format items.
Links Yes No This field indicates if there is a link to a Web site that contains additional information that could help the user to better understand the requirement or the need for the requirement.
Normative Statements Yes No These statements are used to describe the specific rules that a particular Function or Header will operate under. In the 2013 Format, Normative Statements can be the direct children of Headers or Functions and are used to establish a set of criteria to be followed when implementing a particular process. All items are labeled Normative Statements in the 2015 Priority List. Normative Statements in the 2013 Format include one of the qualifiers SHALL, SHOULD, or MAY, that help describe the priority of that statement. Normative Statements in the 2015 Priority List are all Shall statements.
Provenance Yes No Terms used within the Provenance field provide a path tracing the development history of the requirement, in terms of original source and sources of any changes.
Release Package Yes Yes This field indicates if there are related requirements between different release packages, such as a 2013 Format item that is related to a 2015 Priority List item. There may be 0, 1, or >1 related requirements in this field.This field indicates whether a given requirement was part of the 2013 Format release package or as part of the 2015 Priority List release package.
Release Package Related Requirements Yes Yes This field indicates if there are related requirements between different release packages, such as a 2013 Format item that is related to a 2015 Priority List item. There may be 0, 1, or >1 related requirements in this field.
Requirement ID # Yes Yes Specifies the unique identification number of the requirements statement assigned by the USHIK tool.
Requirement Type Yes Yes This field is used to distinguish the general hierarchy role of the requirement and the type of requirement it is meant to represent. There are three primary requirement types called Header, Function, and Normative Statement. The following provides a description of the primary requirement types used:

Header - This term is used to denote a general process to be performed by the system and frequently encapsulates a set of Sub-Headers, Functions, and Normative Statements that make-up the overall requirements tree.

Function - This type of requirement is always a child of a Header and describes a specific process or action performed by the system. Functions are parents of sets of Normative Statements.

Normative Statements - These statements are used to describe the specific rules that a particular Function or Header will operate under. Normative Statements can be the direct children of Headers or Functions and are used to establish a set of criteria to be followed when implementing a particular process. Normative Statements include one of the qualifiers SHALL, SHOULD, or MAY, that help describe the priority of that statement.
See Also Yes No The See Also field helps to identify related requirements. This is mainly used to preserve inter-requirement relationships identified in the HL7 EHR-S Functional Model and HL7 Child Health Functional Profile.
Shall/Should/ May Yes Yes SHALL, SHOULD, and MAY designation is used to filter requirements based on the priority level of the normative statement. For example, requirements that include a SHALL statement would generally be of higher priority than those with a MAY statement.
Status Yes Yes This field indicates that status of the requirement. For the most part, this field should say "released". In other words, the requirement has been released in final form in the current version of the Format.
Title Yes Yes Provides a title for the requirement and is used to provide a brief description of its purpose.
Topic Area(s) Yes Yes A topic area is a broad category that describes the general functional context for a requirement, in terms of what sort of gap(s) it fills. Note that the topic area is not hierarchical and requirements can exist within multiple topic areas. See Table 1 for a list of Topics in the Format.

Provenance within the Format provides the user with an understanding of the root and development path of the requirements structure. For example, some requirements represented in the Format are derived from the HL7 EHR Functional Model or the HL7 Child EHR Functional Profile and consequently their provenance is listed as such. Many of the requirements originate from the Children's EHR Format project's environmental scan and gap analysis prepared by Intermountain Healthcare. Some requirements originate from subject matter experts (SME) within the field of children's health. Many requirements represented in the Format originated from one provenance and were subsequently updated based on the Intermountain Healthcare gap analysis, input from a SME, or both. These requirements are noted in the provenance path with a citation of the original provenance, followed by a citation of a second provenance (for example the Intermountain work), followed by a citation of any subsequent provenances (such an SME contribution) showing the development path of the requirement. This appendix includes detailed information about the classification used within the provenance field of the Format.

Below is a list of each individual provenance used in developing the requirements in the Format. The provenances are sometimes used individually, but more often used in combination depending on the development path of a given requirement. If a base requirement was modified during the development process, the provenance field will include multiple provenances showing the path of development of the requirement. If a base requirement has been modified, the provenance field will shown a "-" after the initial provenance and between any subsequent provenances. For example, Req-1010 has the provenance "HL7 EHR FM R1 - IH Gap Analysis - SME". This Requirement originated from the HL7 EHR Functional Model (HL7 EHR FM R1), was modified based on the Intermountain Healthcare Gap Analysis (IH Gap Analysis), and then father modified by a subject matter expert (SME). All representations in the provenance field will follow this same naming convention as a requirement changed during the development process.

Provenance Description
HL7 CH FP R1 "HL7 Child Health Functional Profile Release 1" - This value identifies requirements that that began initially in the HL7 Child Health Functional Profile Release 1.
HL7 CHWG "HL7 Child Health Work Group" - This value identifies requirements that were created by the HL7 Child Health Work Group prior to the HL7 EHR-S Functional Model Release 1.
HL7 EHR FM R1 "HL7 Electronic Health Record System Functional Model Release 1" - This value identifies requirements that began initially in the HL7 EHR-S Functional Model Release 1.
IH Gap Analysis "Intermountain Healthcare Gap Analysis" - This value identifies the new requirements related to Child Health, which have been identified and recorded by Intermountain Healthcare during their Gap Analysis phase.
SME Subject Matter Experts - This value identifies the new requirements that have been identified by SMEs during the Format development phase.
CCHIT "Certification Commission for Health Information Technology" - This value identifies requirements that began initially in the CCHIT child health certification criteria.
Title Description
Activity Clearance Documentation of physical examination, health history, special conditions or restrictions conducted for the purpose of clearance for a child's enrollment in school or daycare or participation in extracurricular activities such as enrollment in camps, sports teams or lessons, dance or gymnastic lessons, and/or student travel. Includes output, access and exchange formats. Distinct from routine well-child care and documentation.
Birth Information Historical birth and Delivery information is a representation of pertinent post-partum information about the child. This information may be viewed as clinical or demographic.
Child Abuse Reporting Documentation of relevant clinical and family medical and social history for reporting of suspected abuse or abandonment. Child abuse encompasses physical, sexual, and emotional abuse, as well as neglect, Shaken Baby Syndrome, and Fetal Alcohol Syndrome. Interoperability for mandatory reporting.
Child Welfare Documentation of healthcare relevant to foster care, adoption, social work, and Juvenile Justice. Focus on the relevance to wellness, clinical care and family medical and social history; interoperability with protective services.
Children with Special Healthcare Needs Documentation in support of diagnosis and treatment of children with special healthcare needs (i.e., chronic conditions including Attention Deficit Disorder); interoperability with state agencies managing and supporting special healthcare needs; with a focus on system of care. For the purpose of this research Children with Special Health Care Needs (CSHCN) are 0-17 years of age and have a chronic condition and who also require health and related services of a type or amount beyond that required by children generally. Requirements in this area are limited to those that are significantly different than those for the general child/youth population by nature of their specificity, frequency, or potential risk/cost.
EPSDT The EPSDT benefit provides comprehensive and preventive health care services for children under age 21 who are enrolled in Medicaid. This topic area covers documentation in support of meeting the EPSDT requirements and allowing Medicaid providers to document and report services; requires interoperability with State agencies managing Medicaid programs.
Growth Data Documentation and management of multiple entries of typical direct and derived measures of growth such as height, weight, head circumference, BMI and other growth and body composition measures, calculations/conversions, comparisons to growth references "normal ranges", and trending. Includes presentation or visualization of data. Specialty measures of body composition such as skin fold and mid-upper arm circumference measurements are excluded.
Medication Management Medication Management includes ordering, dispensing, administration, and tracking of therapeutic interventions involving a medication that has been prescribed by a licensed independent practitioner (LIP). Special consideration has been taken for dosing, formulation and administration of medications for children, including adjustments to accommodate age- and weight-based dosing. It does not include other forms of treatment that are given via prescription.
Newborn Screening Documentation of neonatal or newborn testing, including tests performed and results, as well as communication with the primary care provider. Ability to adapt to new tests and methods, in contrast to details of specific testing. Neonatal screenings are examinations, testing, and evaluations performed on newborns to screen for genetic, metabolic, and developmental conditions. Neonatal screening requirements vary by state and local governments.
Parents and Guardians and Family Relationship Data Documentation of biological parent, guardian, changes in custody for the purposes of clinical (genetic and environmental) history, family medical and social history and care management, as well as practice management and payment (may overlap with custody and adoption).
Patient Identifier The Patient (Child) Identifier (PI) is the single, primary identifier (derived numerically or logically) that denotes the patient's identity within the Child EHR. PIs are the one to many relational identifiers that connect patients with data elements such as notes, results, or images. This identifier may be retrieved from an identity management system or from within the EHR itself; however the PI should not be confused with the Medical Record number (MRN), encounter number, account number, or other subsystem identifiers (e.g., radiology numbers, clinic numbers) that may have been stored as secondary identifiers within the EHR. Special considerations for accurate and proper identification of children with consideration for coordinated care and interoperability with external systems, as well as linkage to prenatal data. Child identifiers are quite similar to Adult identifiers in most aspects therefore child specific needs are minimal.
Patient Portals - PHR Online access to patient health information or records by patient or parent/guardian; alignment with CHIPPRA special language for access and interoperability; special considerations for security and confidentiality and release of information.
Prenatal Screening Documentation of prenatal testing, as well as documentation and interoperability of communication and education with parents; focus on accommodation for prenatal screening generally, including ability to adapt to new tests and methods, in contrast to details of specific testing.
Primary Care Management ACUTE: Basic management of short term medical care, which can range up to 6 months and possibly more depending on the patient?s needs. Acute care is given to those who are acutely ill, victims of trauma, need monitoring, diagnostic studies, surgery or other treatments, or have an exacerbation of a chronic disorder. This does not include personal care, social services, recuperative, or rehabilitative care. CHRONIC: Care provided for preexisting and persisting illnesses or conditions. Chronic primary care focuses on providing integrated health care for long-term or permanent conditions and illnesses that may potentially alter a patient?s ability to function in life. Chronic primary care not only addresses a specific disease or condition medically, but it also addresses self-care specific to the disease or condition in order to prevent further function loss and to manage life quality through medical, social, psychological, and rehabilitative care. Chronic primary care should not be confused with acute or preventive care.
Quality Measures Collection, documentation and reporting of patient and practice data for the purposes of assessing quality of care, process, or outcomes. Focus on identification of measures specific to care of children. Specific attention to integration of data collection and accommodation of existing or future measures specific to children. Not intended to be an exhaustive list of quality measures or to inventory general interoperability issues (similar to those in adult systems).
Registry Linkages Collection of data elements for contribution to established and future registries, as well as export and formatting of data and interoperability.
School-Based Linkages School-based clinics, care given by school nurses and other forms of school-based health care data must be made accessible in order to gain a comprehensive, longitudinal view of a child's care. School-based linkages focuses on the system interoperability and data exchange between the schools and requesting providers. School-based clinics/nurses, located in schools (private or public) that receive Federal government funding are covered by the Family Educational Rights and Privacy Act (FERPA) rather than HIPAA. Child-focused EHRs that may be deployed in schools must account for the security, privacy and confidentiality rules spelled out in FERPA.
Security and Confidentiality Special requirements for privacy and confidentiality of minor records, including access, consent and authorization, release of information, and special regulations for sexually active minors, emancipated minors.
Special Terminology and Information Where EHR content is coded, accommodation of special terminologies, such as diagnoses, diseases, symptoms, or treatment specific to children.
Specialized Scales/Scoring Scales are a scheme or device by which some property may be measured (such as pain, cognition, lethargy, hardness, weight, or linear dimension). They are based on self-report, observational (behavioral), or physiological data, and can be qualitative or quantitative.
Well Child/Preventive Care A corner stone of ambulatory child health care is the periodic health maintenance visit. Described as the Well-child and Preventive Care Visit or Health Supervision Visit, these visits have age-based periodicity and content. Recommendations for Health Supervision Visits for infants, children, and adolescents are available from multiple organizations including the American Academy of Pediatrics (http://practice.aap.org/content.aspx/aid=1599) , the US Preventive Services Task Force (http://www.uspreventiveservicestaskforce.org/tfchildcat.htm), the American Academy of Family Physicians (http://www.aafp.org), and the Centers for Disease Control (http://www.cdc.gov). In addition, specific content and organization suggestions are available from the Child Health Foundation (http://www.childhealthfoundation.org/).
Scroll To Top