|
|
| (One intermediate revision by the same user not shown) |
| Line 1: |
Line 1: |
| ==17. Production management==
| |
|
| |
|
| Not relevant to medical diagnostic and research labs
| |
|
| |
| ==18. Statistical trending and control charts==
| |
|
| |
| {|
| |
| | STYLE="vertical-align:top;"|
| |
| {| class="wikitable collapsible" border="1" cellpadding="10" cellspacing="0" width=80%
| |
| |-
| |
| ! colspan="1" style="text-align:left; padding-left:20px; padding-top:10px; padding-bottom:10px;"|
| |
| |-
| |
| ! style="color:brown; background-color:#ffffee;"|Requirement and response
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''18.1''' The system should allow authorized users to configure the generation of trending and control charts.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''18.2''' The system should allow authorized users to choose specific sample types, tests, and parameters associated with the statistical trending and control charts that can be generated.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| |}
| |
| |}
| |
|
| |
| ==19. Agriculture and food data management==
| |
|
| |
| Not relevant to medical diagnostic and research labs
| |
|
| |
| ==20. Environmental data management==
| |
|
| |
| Not relevant to medical diagnostic and research labs
| |
|
| |
| ==21. Forensic case and data management==
| |
|
| |
| {|
| |
| | STYLE="vertical-align:top;"|
| |
| {| class="wikitable collapsible" border="1" cellpadding="10" cellspacing="0" width=80%
| |
| |-
| |
| ! colspan="1" style="text-align:left; padding-left:20px; padding-top:10px; padding-bottom:10px;"|
| |
| |-
| |
| ! style="color:brown; background-color:#ffffee;"|Requirement and response
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''21.1''' The system shall be able to assign each piece of collected evidence and each scene a unique identifier using methodologies such as an ID with an incrementing integer (for sequential evidence numbers) or a user-defined naming format for meeting regulatory requirements.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''21.2''' The system shall be able to assign each case a unique case identifier that, in addition to an electronic signature, is able to be automatically placed on, at a maximum, each page of the case's associated examination and administration records.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''21.3''' In addition to a unique case number, the system shall provide a means to add additional information to a case file, including, but not limited to, submitting agency, agency case number, date of case receipt, name of recipient, shipping and receipt details, items associated with the case and their unique designators, notes, test data, related reports, and other documentation.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''21.4''' The system should be able to document evidence using an ASTM-compliant evidence log, including, but not limited to, unique identifiers, investigator and custodian names, key dates and times, evidence conditions, and storage location.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''21.5''' The system should be able to prevent a piece of evidence from being scheduled for destructive testing until an appropriate authorization for such analysis is acquired and documented.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''21.6''' The system shall be able to record and maintain chain of custody of evidence that is subdivided in the laboratory in the same way that original evidence items are tracked.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''21.7''' The system shall be capable of recording the secondary dissemination to an authorized agency or organization of criminal history record information (CHRI) sourced from U.S. Criminal Justice Information Services (CJIS).<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''21.8''' The system shall be able to record all National Crime Information Center (NCIC) and Interstate Identification Index (III) data transactions, clearly identifying the operator and authorized receiving agency or organization. III records shall also identify requester and recipient using a unique identifier.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''21.9''' If the system provides remote access to authorized users over authorized devices, the remote access shall be monitored, controlled and documented, particularly for privileged functions. If remote access to privileged functions is allowed, virtual escorting that meets CJIS Security Policy 5.5.6 conditions will be required.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''21.10''' The system shall be capable of putting into place, in their entirety, either the "basic password standards" or "advanced password standards" described in CJIS Security Policy 5.6.2.1.1.1 and 5.6.2.1.1.2. If PIN and/or one-time password is also used, the attributes in 5.6.2.1.2 and 5.6.2.1.3 shall also be required.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''21.11''' If the system supports user-based certificates for authentication, the system shall be configurable enough to require them to be 1. user-specific, not device-specific, 2. used only by one user at any given time, and 3. activated for each use by, e.g., a passphrase or PIN.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''21.12''' The system shall allow "encryption in transit" and "encryption at rest" of criminal justice information (CJI) that meets or exceeds the requirements of CJIS Security Policy 5.10.1.2.1 and 5.10.1.2.2.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''21.13''' If the system is cloud-based, the vendor shall ensure that CJI is stored in databases located within the physical boundaries of APB-member countries and within the legal authority of APB-member agencies. Additionally, the vendor shall agree to not use any metadata derived from unencrypted CJI for commercial, advertising, or other purposes, unless specifically permitted for limited within the service agreement.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''21.14''' If the system is cloud-based, the vendor should agree to FBI and CSA compliance and security audits of CJI.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''21.15''' If the system is capable of being run in a virtual environment, it shall meet the virtualization requirements set forth in CJIS Security Policy 5.10.3.2 and best practices set forth in CJIS Security Policy Appendix G.1.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''21.16''' The system should provide separate processing domains in order to not only allow for more granular allocation of user privileges, but also to prevent one process from modifying the executing code of another process.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''21.17''' The system should support the use of personal identity verification—a U.S. Federal government-wide credential system—and other forms of hardware-based (i.e., public key infrastructure or PKI) token authentication, while electronically verifying those credentials and any configured token quality requirements.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| |}
| |
| |}
| |
|
| |
| ==22. Public health data management==
| |
|
| |
| {|
| |
| | STYLE="vertical-align:top;"|
| |
| {| class="wikitable collapsible" border="1" cellpadding="10" cellspacing="0" width=80%
| |
| |-
| |
| ! colspan="1" style="text-align:left; padding-left:20px; padding-top:10px; padding-bottom:10px;"|
| |
| |-
| |
| ! style="color:brown; background-color:#ffffee;"|Requirement and response
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''22.1''' The system should be capable of interfacing with the Center for Disease Control and Prevention's PHIN Messaging System.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| |}
| |
| |}
| |
|
| |
| ==23. Veterinary data management==
| |
|
| |
| {|
| |
| | STYLE="vertical-align:top;"|
| |
| {| class="wikitable collapsible" border="1" cellpadding="10" cellspacing="0" width=80%
| |
| |-
| |
| ! colspan="1" style="text-align:left; padding-left:20px; padding-top:10px; padding-bottom:10px;"|
| |
| |-
| |
| ! style="color:brown; background-color:#ffffee;"|Requirement and response
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''23.1''' The system should support standardized veterinary clinical terminology such as that found in the Veterinary Extension of SNOMED CT and the Veterinary Nomenclature (VeNom) Codes.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''23.2''' The system should be able to exchange data, when necessary, in a fashion that meets International Committee for Animal Recording (ICAR) and Veterinary International Conference on Harmonization (VICH) electronic data exchange guidelines.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''23.3''' The system should support National Animal Health Laboratory Network (NAHLN), and, by extension, Health Level 7 (HL7) result messaging.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| |}
| |
| |}
| |
|
| |
| ==24. Scientific data management==
| |
|
| |
| {|
| |
| | STYLE="vertical-align:top;"|
| |
| {| class="wikitable collapsible" border="1" cellpadding="10" cellspacing="0" width=80%
| |
| |-
| |
| ! colspan="1" style="text-align:left; padding-left:20px; padding-top:10px; padding-bottom:10px;"|
| |
| |-
| |
| ! style="color:brown; background-color:#ffffee;"|Requirement and response
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''24.1''' The system shall capture raw instrument data and metadata either as an electronic file or directly via RS-232 or TCP/IP communication.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''24.2''' The scientific data management system (SDMS) should provide a checksum verification of source and destination data and store that verification data in a secure server with controlled access.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''24.3''' The system shall store metadata related to raw instrument data in a database in such a way that the original data generated by instruments for specific samples and tests is easy to retrieve.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''24.4''' The system should be capable of capturing a complete and readable copy of original data and any previous versions of modified data in order to maintain the integrity of that data.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''24.5''' The system should secure raw data such that it can't be deleted and provide version control when data is modified by any user or specific software.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''24.6''' The SDMS should provide tools for helping a laboratory achieve the U.S. Food and Drug Administration's defined ALCOA principles.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''24.7''' The SDMS shall provide security and access controls for protecting stored data.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''24.8''' The SDMS shall record an audit trail for each and every record created and modified, using version control.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''24.9''' The SDMS shall record an audit trail for each and every record created and modified, using version control.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| |}
| |
| |}
| |
|
| |
| ==25. Health information technology==
| |
|
| |
| {|
| |
| | STYLE="vertical-align:top;"|
| |
| {| class="wikitable collapsible" border="1" cellpadding="10" cellspacing="0" width=80%
| |
| |-
| |
| ! colspan="1" style="text-align:left; padding-left:20px; padding-top:10px; padding-bottom:10px;"|
| |
| |-
| |
| ! style="color:brown; background-color:#ffffee;"|Requirement and response
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''25.1''' The electronic health record (EHR) module should provide computerized provider order entry (CPOE) functionality for medication orders, laboratory orders, and diagnostic imaging, including making checks for potential drug-drug and drug-allergy interactions.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''25.2''' The EHR module should allow authorized personnel to record, change, and access patient demographic data, including, but not limited to, race and ethnicity, patient's preferred language, birth sex, current sex, sexual orientation, gender identity, birth date, smoking status, alcohol use, family health history, psychological aspects, social aspects, and behavioral aspects.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''25.3''' The EHR module should allow authorized personnel to record, change, and access a patient's active problem list, medication list, medication allergy list, preferred drug list, and implantable device list, incorporating, where appropriate, at a minimum the SNOMED CT nomenclature standard.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''25.4''' The EHR module should incorporate configurable, role-based clinical decision support tools capable of allowing authorized personnel to trigger electronic interventions based on liked reference information standardized to Health Level 7 (HL7) Version 3 implementation guides. The reference information should be sourced.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''25.5''' The EHR module should be able to identify education resources specific to a patient's active problem and medication lists. The educational resources should be standardized to Health Level 7 (HL7) Version 3 implementation guides.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''25.6''' The EHR module should allow authorized personnel to create, view, send, and receive transition of care or referral summaries in such a way that the summary is properly formatted, matched to the correct patient, and reconciled according to the standards and protocols outlined in 45 CFR Part 170.315 (b-1), (b-2), (b-4), and (b-5).<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''25.7''' The EHR module should allow authorized personnel to conduct electronic prescribing actions such as creating, changing, cancelling, and refilling prescriptions, incorporating at least the RxNorm and NCPDP SCRIPT standards.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''25.8''' The EHR module should allow authorized personnel to configure, create, and store data exports, incorporating at least HL7 Version 3 implementation standards, as well as SNOMED CT and ICD-9 standards.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''25.9''' The EHR module should allow for the secure creation, sending, and receipt of restricted summary records, incorporating HL7 Version 3 implementation standards.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''25.10''' The EHR module should allow authorized personnel to create, record, change, access, and receive care plan information, incorporating HL7 Version 3 implementation standards.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''25.11''' The EHR module should provide a means to record, calculate, import, export, filter, and report on clinical quality measures according to the standards outlined in 45 CFR Part 170.315 (c).<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''25.12''' The EHR module shall provide security and access controls for protecting stored data.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''25.13''' The EHR module shall record an audit trail for each and every record created and modified, using version control.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''25.14''' The EHR module shall either encrypt electronic health information on end-user devices after use of the technology on the device stops or prevent electronic health information from being stored on end-user devices after use of the technology on the device stops.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''25.15''' The EHR module shall ensure that electronically exchanged health information has not been altered during the transfer process, using at least a hashing algorithm secured to SHA-2 or better.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''25.16''' The EHR module should be capable of recording patient disclosures made for treatment, payment, and health care operations.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''25.17''' The EHR module should provide a means for patients and their authorized representatives to view, download, and transmit their personal health information and activity history log from the EHR via an internet-based technology, using the standards outlined in 45 CFR Part 170.315 (e-1).<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''25.18''' The EHR module should provide a means for authorized users to securely send messages to and receive messages from patients, at the same time allowing for the recording, accessing, and linking of information shared by the patient electronically (as well as directly).<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''25.19''' The EHR module should allow vital patient information as it relates to public health to be transmitted to immunization registries, cancer registries, and public health agencies, as well as be accessed after the fact. This includes, but is not limited to, immunization history, surveillance information, laboratory test results, cancer case information, case reports, antimicrobial reporting, and health care survey information.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''25.20''' The EHR developer should use user-centered and accessibility-centered design processes for creating and testing the EHR's functionality. A quality management system should be used during these processes.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''25.21''' The EHR module's use of clinical document architecture (CDA) should be demonstrated and verified for conformance to the standards identified in 45 CFR Part 170.315 (g-6).<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| | style="padding:10px; background-color:white;" |'''25.22''' The EHR module should include an application programming interface (API) that demonstrates the EHR's ability to uniquely identify a patient and corresponding ID/token in a received records or data category request in order to accurately and securely meet the request for that patient's data. The API should be well documented.<br /> <br /><div align="center"><hr width=60%></div><br/>'''RESPONSE''': <br /> <br />
| |
| |-
| |
| |}
| |
| |}
| |
