Become a Member

Health Information Technology Standards

Functional Standards

Organizations that Develop Functional Standards | Tutorials

Functional Standards describe, in an organized format, the participants (people and information systems), required functions & features and operational capabilities needed in a Software Application as defined by a qualified group of users (domain experts/stakeholders). Functional requirements are derived from the description of userís business activities (business requirements). Business requirements aim to explain why a Software Application is needed. Functional standard describes what a Software Application must do, i.e., functional requirements, by translating Business Requirements into the following five functional categories:

  1. Collect/Input Data, i.e., get data into the Software Application
  2. Manage Data, i.e., receive data, verify data, store data, send data
  3. Analyze Data, i.e., group data by similar attributes (location, condition, etc.)
  4. Integrate Data, i.e. receive data from more than one data system/source
  5. Generate Output, i.e., reports, summaries, alerts, notifications, etc.

For example, patientís visit to a doctor (business activity) creates encounter data that the doctor will record/enter (collect data) in the Electronic Health Record System (EHR-S). This data entry has to be checked for quality assurance and added into the patientís medical record in the EHR-S (manage data). This encounter data can be compared with the previous encountersí data on this patient or with other patientsí data (analyze data). This encounter data may include medication prescription to be sent to a Pharmacy information system (integrate data). This encounter data may be given to a patient as a visitís summary or has to be reported to a Public Health Agency (generate output).

Functional requirements are written by users (stakeholders) in a non-technical language in an organized format of the Functional Requirements Analysis Document (FRAD). FRAD is used in software engineering to summarize the userís functional requirements for a Software Application.

The Functional Requirements Analysis Document includes the following components:

  1. Description of the Problem (business activity and health information exchange needs related to this activity) that the Software Application will help to address
  2. Goal of the Software Application
  3. Actors (stakeholders and other information systems (data sources)) that will interact with the Software Application
  4. Functions (Actions) that the Software Application will support
  5. Non-Functional Requirements for the Software Application, e.g., privacy & security requirements
  6. Use Case Description - a real clinical or public health scenario that describes the use of the software application in the context of actorsí work Processes
  7. Unified Modeling Language (UML) Diagrams that depict actors and actions interactions in the context of the Software Application, i.e., Use Case Diagram and Workflow & Dataflow Diagram
  8. High-Level Architecture of the Software Application Hardware and Software Requirements
  9. Evaluation of the Software Application Development
  10. Timeline for the Software Application Development

A Functional standard is a vehicle to assure that the work processes of users related to the a particular business activity, i.e., patient care management, public health surveillance, etc., that involve electronic data exchanges are well understood and agreed upon first by users themselves and then communicated clearly to the developers as functional requirements for a Software Application.

Functional Standards
Examples of Standards Development Organizations Domains
ASTM Healthcare
HL7 Healthcare, Public Health
ISO Healthcare
PHDSC Clinical - Public Health Information Exchanges

ASTM Committee E31 Ė American Standards for Testing and Materials Committee E31 on Health Informatics

ASTM International is one of the largest voluntary standards development organizations in the world- for technical standards for materials, products, systems, and services.

ASTM Committee E31 on Healthcare Informatics develops standards related to the architecture, content, storage, security, confidentiality, functionality, and communication of information used within healthcare and healthcare decision making, including patient-specific information and knowledge. The Committee, with a current membership of approximately 300 members, has 3 technical subcommittees that have over 30 approved standards and additional draft standards

HL7 - Health Level Seven

HL7 develops standards for the exchange, management, and integration of data that support clinical patient care and the management, delivery, and evaluation of health care services. HL7 developed a functional model for Electronic Health Record Systems (EHR-S) and Personal Health Record Systems (PHR-S).

HL7 Electronic Health Record System (EHR-S) Functional Model Draft Standard for Trial Use (EHR-S DSTU) provides strong benefits for public health information systems. At the request of the EHR Collaborative, the Consortium launched a PHDSC Ad Hoc Task Force on Electronic Health Record Ė Public Health (EHR-PH) to evaluate the EHR-S DSTU from the public health perspective. Cross mapping the HL7 EHR functions to core public health functions and interventions demonstrates that core public health functions are well represented in the EHR-S DSTU, and that the EHR-S DSTU provides a foundation for integration of healthcare and public health services and has the necessary functionality for reporting and sharing information across clinical and public health systems.

In 2007 HL7 launched an effort to develop a second functional model, this time focused on the Personal Health Record (PHR). A number of Consortium members worked directly with the HL7 technical committees to ensure that public healthís interests were properly represented in this consumer-centric model. As Personal Health Record Systems (PHR-S) begin to proliferate, it is important that their potential role in public health surveillance and other public health activities is properly recognized and developed.

ISO - International Organization for Standardization

ISO is a network of national standards institutes from 140 countries working in partnership with international organizations, governments, industry, business, and consumer representatives.

ISO 215 Technical Committee on Health Informatics (ISO/TC 215) works on the standardization of health information and communications technology to allow for compatibility and interoperability between independent systems through the following Working Groups:

  • WG 1: Data Structure
  • WG 2: Messaging and Communications
  • WG 3: Health Concept Representation
  • WG 4: Security
  • WG 5: Health Cards
  • WG 6: Pharmacy and Medication
  • WG 7: Devices
  • WG 8: Business Requirements for Electronic Health Records

The ISO/TC 215 developed functional standards for Electronic Health Record Systems.

ISO/TC 215 Standards List

PHDSC - Nationwide Health Information Network Committee

With support from the Health Resources and Services Administration (HRSA), the PHDSC Nationwide Health Information Network Committee worked on the development of functional standards for electronic health information exchanges between clinical care and public health in the domains of school health, syndromic surveillance and diabetes care management and surveillance.

PHDSC documented userís needs for interoperable information systems in these domains in a standardized Functional Requirement Analysis Document (FRAD) using the PHDSC FRAD development methodology that follows the standard software requirement elicitation and documentation process. In this process users and developers define the goals of the information system, the actors that will interact with the system, the functional and non-functional requirements of the system, the use case scenario(s), the data sources used by the system, and the workflow and dataflow that the system will support. The purpose of the FRAD is to help users of the information system to specify (explain) system requirements (userís needs that the system must support) for developers in an organized way and in a language that both users and developers will understand.