It's still Wednesday at the HL7WGM (barely)

It's been too long since I've written an HL7 Plenary Wednesday post, but if you understand the history of this blog, you know what is coming.  For rather understandable reasons, I have shifted a great deal of my focus towards implementations and standards supporting Public Health, rather than the EHR space.  Some of that has to do with what my employer Audacious Inquiry does, but other parts of that stem from seeing an unmet need that can impact people around my country, and even more so, the public health people working very hard, and on very limited budgets to keep us all healthy.  That unmet need became even more apparent as we went through COVID-19 and are still in many ways recovering from it.

Significant effort is underway even now to connect public health to the health information eco-system that we in HL7, IHE and other organizations have been creating for patients.  One of those efforts is to enable public health agencies to connect to that eco-system through TEFCA and national networks to make it easier, cheaper and faster to do the jobs that need to be done, and to improve the infrastructure that is long overdue for a major upgrade.

Over the last couple of years, I met a young leader whose team is developing tools to enable public health agencies connect to the Health Information Superhighway we have been trying to create for the past two decades. Over the past year, I worked closely with him and his team at two different FHIR Connectathon events to better enable agencies to build on-ramps to that expressway.  Through his work, I've been able to make some on-ramps of my own that should enable public health agencies better access to their own data using a more modern infrastructure and achieve a five-year goal I set for myself back in early 2021.

This next recipient is someone I've not had a chance to watch over a long period of time, nor see him grow (though I know he has even in the short time I've known him).  He does what all good leaders do, which is to enable others to succeed, and by others, in this case, I mean me.  We have infrequent contact, we don't really work on the same project, but where our roles intercept, he's made it possible for me achieve a significant goal. Without further ado, here's the next Ad Hoc Harley.

For Daniel Paseltiner, of Skylight 

For leadership that enabled me an opportunity to nail a 5-year goal

P.S. I know this post was more about me than Dan, and for that, I'm sorry.  I do wish Dan and I had more opportunities to work more closely together on a project.  To see some of the work of Dan and his team, check out the DIBBS Query Connector project on GitHub.

   

A syntax for validating V2toFHIR Conversions

I've been working on V2toFHIR since its inception.  A month ago, and back in January I participated in two Connectathons that are using that capability from this code.  In building that engine, I needed a way to test a conversion of an HL7 message in a way that would make it easier for me to write detailed tests.

The input to a test is an HL7 V2 message with segments.  A very long time ago, I resolved to use plain-text files containing messages and divide them with a blank line.  Here's an example below of a file with two messages I've previously used for other purposes at IHE Connectathons (I have several years of IHE Connectathon test data lying about):

# Outbound ack:

MSH|^~\&|PAT_IDENTITY_X_REF_MGR_MISYS_TLS|ALLSCRIPTS|OTHER_IBM_BRIDGE_TLS|IBM|20090224114149-0500||ACK^A04|OpenPIXPDQ10.243.0.65.19767899354465|P|2.3.1

MSA|AA|0851077658473390286

# PIX Feed (ADT^A01)

# Inbound feed:

MSH|^~\&|OTHER_IBM_BRIDGE_TLS|IBM|PAT_IDENTITY_X_REF_MGR_MISYS|ALLSCRIPTS|20090224104152-0600||ADT^A01^ADT_A01|8686183982575368499|P|2.3.1

EVN||20090224104152-0600

PID|||102^^^IBOT&1.3.6.1.4.1.21367.2009.1.2.370&ISO||SINGLETON^MARION||19661109|F

PV1||I

You might also note that I allow for comment characters at the start of the line. My test framework simply ignores those lines while reading the test data, and if gives me a way to identify the test case. For testing V2 to FHIR Conversions, I needed a way to create assertions that would be used to verify the assertion.  Of course, FHIRPath comes to mind because it's already an expression language widely used in FHIR itself for assertions and other manipulations of FHIR Resources.  That's ideal language for my use case.

So, I added a capability in my test case reader to add assertions to the test case. Here's an example for the first test case above.  The @ sign introduces an assertion.

@MessageHeader.source.name = "PAT_IDENTIFY_X_REF_MGR_MISYS_TLS"

@MessageHeader.source.endpoint = "ALLSCRIPTS"

@MessageHeader.destination.name = "OTHER_IBM_BRIDGE_TLS"

@MessageHeader.destination.endpoint = "IBM"

I'm actually checking a bundle but use a little string substitution hackery to replace MessageHeader with %context.entry.resource.ofType(MessageHeader) at the head of the expression to save me about 31 characters of typing each time.

The next bit of fun is enabling the assertions to come close to where they are useful in the message.  It should be obvious that each test case has two streams of data, the message, and the assertions.  They can easily be interwoven.  So, assertions can easily follow the segment, but I also wanted more, because some segments can be very long.  Borrowing from other scripting languages (e.g., bash), I allow the introduction of the \ character at the end of the line to allow lines to be continued.  I realized that it would be important to visually see the start an end of a segment in the file, so I ignore leading whitespace at the beginning of continuation lines.  So now I can write:

# Outbound ack:

MSH|^~\&|\

PAT_IDENTITY_X_REF_MGR_MISYS_TLS|\

@MessageHeader.source.name = "PAT_IDENTIFY_X_REF_MGR_MISYS_TLS"

ALLSCRIPTS|\

@MessageHeader.source.endpoint = "ALLSCRIPTS"

OTHER_IBM_BRIDGE_TLS|\

@MessageHeader.destination.name = "OTHER_IBM_BRIDGE_TLS"

IBM|20090224114149-0500|\

@MessageHeader.destination.endpoint = "IBM"

|ACK^A04|OpenPIXPDQ10.243.0.65.19767899354465|P|2.3.1

MSA|AA|0851077658473390286

And so forth.  In this way, I now have a test case where I can start with the message in my usual form (simple text with a blank line between cases).  From there I can augment the test case with assertions that I feel are important.  Following that, I can also break things up, even just long lines of V2 messages to make the test files more readable.

The final piece of this was to allow long assertions to be broken up the same way messages are, and to steal the final comment in the assertion expression (comments are part of FHIRPath syntax) to use for my assertion message in my testing framework.  That's also just simple string substitution as well.

You can find all of the code for this in V2toFHIR, the open-source converter my team and I created for some of our ongoing work.  The two key files of interest are MessageParserTests.java and TestData.java.  The method TestData.load() is where all the test input parsing magic happens.  It's not really that complicated.

Code generators need not be perfect

Le mieux est le mortel
ennemi du bien. -- Voltaire

I've been working on expanding the v2tofhir code that Audacious Inquiry developed for one of our projects into a broader offering for public health that handles more than just Immunization messages.  That's not going back into the original open-source work, as it is not within the scope of that program. But it is going to become an application available to our customers. Contact me if you want to learn more.

One thing I relearned from my vibe coding session with Copilot is that code generators don't have to be perfect -- although it certainly helps if they are.  I already know from years of experience working with natural language processing is that heuristics can often get you most of the way there, and specialized exception handling can handle what the heuristic doesn't.

By putting these two ideas together I can successfully generate code for the 2700+ mapping rules in the current HL7 V2 to FHIR specification in just minutes.   This makes my code generator immediately effective to support the 75 or so segment mapping tables supported by that specification. With a few minutes, I can generate code to support every segment, and within a few hours more, can correct all of the missing bits.  

The compiler is a perfect tool for detecting the exception cases. Like a canary in a coal mine, it is especially sensitive to danger. The code generator I'm still developing has been an excellent QA resource for the HL7 V2 to FHIR spec, as it enables me to verify content in the spec.  Some errors in the generated output are actually caused by typos in the over 10000 lines of CSV data that is used to generate the HL7 standard.

This is a tremendous lift for development, and as we figure out the patterns of errors, we can easily augment the code generator to fix them.  While that's being done, we still have code that we can tweak to perfection in much less time than it takes to generate it manually.  It also reduces the amount of SME expertise needed to create the application.  

The original open-source code took a more manual approach to automation (I was actually trying to figure out the process in using spreadsheets).  It took about 3 months of work to handle about 20 segments.  Easily half of that was putting together the surrounding infrastructure rather than parsing individual segments.  The code generator took about a week to build.  It gets very close to final code for 75 segments.  These leave me about 40-50 errors to resolve, most of which are simple.  I'm expecting another week or two will be needed to handle those issues in the generated code.  This is easily an order of magnitude improvement. It can be repeated on new editions of the V2 to FHIR outputs much faster than fixing the code by hand, which also speeds up maintenance.

Two Guys in a Garage

COVID-19 impacted many things in a bad way but also had some beneficial impacts on Public Health infrastructure and adjoining technologies. This long overdue post recognizes a small team whose impact on Public Health data has been tremendous. In my work on IZ Gateway, I was first introduced to these two entrepreneurs, almost literally two guys in a garage, who had developed a wicked cool application. While I cannot personally benefit from this application today, my brother and his family live in a state where, because of this application, they can access their immunization data directly from the New Jersey IIS. 

 I got to work with this team a couple of years ago at a demonstration of the IZ Gateway and their application, and on the last day of the Interoperability Showcase, I got to be the demonstrator pitching what this application does to the showcase audience. The application they have built is truly an engine for change. This Ad Hoc Harley goes to two guys, Michael Perretta and Nathan Scott, founders of Docket, who have truly shown what can be done with the right vision and skills.

This Certifies that

Michael Perretta and Nathan Scott

Have been hereby recognized for being engines of change in Public Health

Imagine riding with this engine under your seat.

HIPAA Security Section 312 Changes

Earlier this week I provided a side-by-side comparison of the HIPAA section 308 changes.  Today I have a similar sheet for Section 312.  Next week I should have a summary prepared of what this comparison tells you.

Once again, green background is new content.  Yellow background is mostly unchanged, and red background is stuff that has been removed from the rule (there's not much that was removed).  

New Section #	New Text	Old Section #	Old Text
312	§ 164.312 Technical safeguards.	312	§ 164.312 Technical safeguards.
	Each covered entity or business associate must, in accordance with §§ 164.306 and 164.316, implement all of the following technical safeguards, including technical controls, to protect the confidentiality, integrity, and availability of all electronic protected health information that it creates, receives, maintains, or transmits:		A covered entity or business associate must, in accordance with § 164.306:
312(a)	(a) Standard: Access control	312(a)(1)	(a) (1) Standard: Access control.
312(a)(1)	—(1) General.
	Deploy technical controls in relevant electronic information systems to allow access only to users and technology assets that have been granted access rights.		Implement technical policies and procedures for electronic information systems that maintain electronic protected health information to allow access only to those persons or software programs that have been granted access rights as specified in § 164.308(a)(4).
312(a)(2)	(2) Implementation specifications	312(a)(2)	(2) Implementation specifications:
312(a)(2)(i)	—(i) Unique identification.	312(a)(2)(i)	(i) Unique user identification (Required).
	Assign a unique name, number, and/or other identifier for tracking each user and technology asset in the covered entity or business associate's relevant electronic information systems.		Assign a unique name and/or number for identifying and tracking user identity.
312(a)(2)(ii)	(ii) Administrative and increased access privileges.
	Separate user identities from identities used for administrative and other increased access privileges.
312(a)(2)(iii)	(iii) Emergency access procedure.	312(a)(2)(ii)	(ii) Emergency access procedure (Required).
	Establish (and implement as needed) written and technical procedures for obtaining necessary electronic protected health information during an emergency.		Establish (and implement as needed) procedures for obtaining necessary electronic protected health information during an emergency.
312(a)(2)(iv)	(iv) Automatic logoff.	312(a)(2)(iii)	(iii) Automatic logoff (Addressable).
	Deploy technical controls that terminate an electronic session after a predetermined time of inactivity that is reasonable and appropriate.		Implement electronic procedures that terminate an electronic session after a predetermined time of inactivity.
312(a)(2)(v)	(v) Log-in attempts.
	Deploy technical controls that disable or suspend the access of a user or technology asset to relevant electronic information systems after a reasonable and appropriate predetermined number of unsuccessful authentication attempts.
312(a)(2)(vi)	(vi) Network segmentation.
	Deploy technical controls to ensure that the covered entity's or business associate's relevant electronic information systems are segmented in a reasonable and appropriate manner.
312(a)(2)(vii)	(vii) Data controls.
	Deploy technical controls to allow access to electronic protected health information only to those users and technology assets that have been granted access rights to the covered entity's or business associate's relevant electronic information systems as specified in § 164.308(a)(10).
312(a)(2)(viii)	(viii) Maintenance.
	Review and test the effectiveness of the procedures and technical controls required by this paragraph (a)(2) at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.
312(b)	(b) Standard: Encryption and decryption
312(b)(1)	—(1) General.
	Deploy technical controls to encrypt and decrypt electronic protected health information using encryption that meets prevailing cryptographic standards.	312(a)(2)(iv)	(iv) Encryption and decryption (Addressable).  Implement a mechanism to encrypt and decrypt electronic protected health information.
312(b)(2)	(2) Implementation specification.
	Encrypt all electronic protected health information at rest and in transit, except to the extent that an exception at paragraph (b)(3) of this section applies.	312(e)(2)(ii)	(ii) Encryption (Addressable).  Implement a mechanism to encrypt electronic protected health information whenever deemed appropriate.
312(b)(3)	(3) Exceptions.
	This paragraph (b)(3) applies only to the electronic protected health information directly affected by one or more of the following exceptions and only to the extent that the covered entity or business associate documents that an exception applies and that all other applicable conditions are met.
	(i) The technology asset in use does not support encryption of the electronic protected health information consistent with prevailing cryptographic standards, and the covered entity or business associate establishes and implements a written plan to migrate electronic protected health information to a technology asset that supports encryption consistent with prevailing cryptographic standards within a reasonable and appropriate period of time.
	(ii) An individual requests pursuant to § 164.524 to receive their electronic protected health information in an unencrypted manner and has been informed of the risks associated with the transmission, receipt, and storage of unencrypted electronic protected health information. This exception does not apply where such individual will receive their electronic protected health information pursuant to § 164.524 and the technology used by the individual to receive the electronic protected health information is controlled by the covered entity or its business associate.
	(iii) During an emergency or other occurrence that adversely affects the covered entity's or business associate's relevant electronic information systems in which encryption is infeasible, and the covered entity or business associate implements reasonable and appropriate compensating controls in accordance with and determined by the covered entity's or business associate's contingency plan under § 164.308(a)(13).
	(iv) The technology asset in use is a device under section 201(h) of the Food, Drug, and Cosmetic Act, 21 U.S.C. 321(h) that has been authorized for marketing by the Food and Drug Administration, as follows:
	(A) Pursuant to a submission received before March 29, 2023, provided that the covered entity or business associate deploys in a timely manner any updates or patches required or recommended by the manufacturer of the device.
	(B) Pursuant to a submission received on or after March 29, 2023, where the device is no longer supported by its manufacturer, provided that the covered entity or business associate has deployed any updates or patches required or recommended by the manufacturer of the device.
	(C) Pursuant to a submission received on or after March 29, 2023, where the device is supported by its manufacturer.
	(4) Alternative measures
	—(i) Alternative measures.
	Where an exception at paragraph (b)(3) of this section applies, a covered entity or business associate must document in real-time the existence of an applicable exception and implement reasonable and appropriate compensating controls in accordance with paragraph (b)(4)(ii) of this section.
	(ii) Compensating controls.
	(A) To the extent that a covered entity or business associate determines that an exception at paragraph (b)(3)(i), (ii), or (iii) or (b)(3)(iv)(A) or (B) of this section applies, the covered entity or business associate must secure such electronic protected health information by implementing reasonable and appropriate compensating controls reviewed and approved by the covered entity's or business associate's designated Security Official.
	(B) To the extent that a covered entity or business associate determines that an exception at paragraph (b)(3)(iv)(C) of this section applies, the covered entity or business associate shall be presumed to have implemented reasonable and appropriate compensating controls where the covered entity or business associate has deployed the security measures prescribed and as instructed by the authorized label for the device, including any updates or patches recommended or required by the manufacturer of the device.
	(C) To the extent that a covered entity or business associate is implementing compensating controls under this paragraph (b)(4)(ii), the implementation and effectiveness of compensating controls must be reviewed, documented, and signed by the designated Security Official at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, to continue securing electronic protected health information and relevant electronic information systems.
	(5) Maintenance.
	Review and test the effectiveness of the technical controls required by this paragraph (b) at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.
312(c)	(c) Standard: Configuration management
	—(1) General.
	Establish and deploy technical controls for securing the covered entity's or business associate's relevant electronic information systems and technology assets in its relevant electronic information systems, including workstations, in a consistent manner, and maintain such electronic information systems and technology assets according to the covered entity's or business associate's established secure baselines.
	(2) Implementation specifications
	—(i) Anti-malware protection.
	Deploy technology assets and/or technical controls that protect all of the covered entity's or business associate's technology assets in its relevant electronic information systems against malicious software, including but not limited to viruses and ransomware.
	(ii) Software removal.
	Remove extraneous software from the covered entity's or business associate's relevant electronic information systems.
	(iii) Configuration.
	Configure and secure operating system(s) and software consistent with the covered entity's or business associate's risk analysis under § 164.308(a)(2).
	(iv) Network ports.
	Disable network ports in accordance with the covered entity's or business associate's risk analysis under § 164.308(a)(2).
	(v) Maintenance.
	Review and test the effectiveness of the technical controls required by this paragraph (c) at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.
312(d)	(d) Standard: Audit trail and system log controls	312(b)	(b) Standard: Audit controls.
312(d)(1)	—(1) General.
	Deploy technology assets and/or technical controls that record and identify activity in the covered entity's or business associate's relevant electronic information systems.		Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.
312(d)(2)	(2) Implementation specifications
	—(i) Monitor and identify.
	The covered entity or business associate must deploy technology assets and/or technical controls that monitor in real-time all activity in its relevant electronic information systems, identify indications of unauthorized persons or unauthorized activity as determined by the covered entity's or business associate's risk analysis under § 164.308(a)(2), and alert workforce members of such indications in accordance with the policies and procedures required by § 164.308(a)(7).
	(ii) Record.
	The covered entity or business associate must deploy technology assets and/or technical controls that record in real-time all activity in its relevant electronic information systems.
	(iii) Retain.
	The covered entity or business associate must deploy technology assets and/or technical controls to retain records of all activity in its relevant electronic information systems as determined by the covered entity's or business associate's policies and procedures for information system activity review at § 164.308(a)(7)(ii)(A).
	(iv) Scope.
	Activity includes creating, accessing, receiving, transmitting, modifying, copying, or deleting any of the following:
	(A) Electronic protected health information.
	(B) Relevant electronic information systems and the information therein.
	(v) Maintenance.
	Review and test the effectiveness of the technology assets and/or technical controls required by this paragraph (d) at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.
	(e) Standard: Integrity.	312(c)(1)	(c)(1) Standard: Integrity.
	Deploy technical controls to protect electronic protected health information from improper alteration or destruction, both at rest and in transit;		Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.
	and review and test the effectiveness of such technical controls at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.
		312(c)(2)	(2) Implementation specification: Mechanism to authenticate electronic protected health information (Addressable).  Implement electronic mechanisms to corroborate that electronic protected health information has not been altered or destroyed in an unauthorized manner.
		312(e)(2)(i)	(i) Integrity controls (Addressable).  Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of.
312(f)	(f) Standard: Authentication	312(d)	(d) Standard: Person or entity authentication.
	—(1) General.
	Deploy technical controls to verify that a person or technology asset seeking access to electronic protected health information and/or the covered entity's or business associate's relevant electronic information systems is the one claimed.		Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed.
	(2) Implementation specifications
	—(i) Information access management policies.
	Deploy technical controls in accordance with the covered entity's or business associate's information access management policies and procedures under § 164.308(a)(10), including technical controls that require users to adopt unique passwords that are consistent with the current recommendations of authoritative sources.
	(ii) Multi-factor authentication.
	(A) Deploy multi-factor authentication to all technology assets in the covered entity's or business associate's relevant electronic information systems to verify that a person seeking access to the relevant electronic information system(s) is the user that the person claims to be.
	(B) Deploy multi-factor authentication for any action that would change a user's privileges to the covered entity's or business associate's relevant electronic information systems in a manner that would alter the user's ability to affect the confidentiality, integrity, or availability of electronic protected health information.
	(iii) Exceptions.
	Deployment of multi-factor authentication is not required in any of the following circumstances.
	(A) The technology asset in use does not support multi-factor authentication, and the covered entity or business associate establishes and implements a written plan to migrate electronic protected health information to a technology asset that supports multi-factor authentication within a reasonable and appropriate period of time.
	(B) During an emergency or other occurrence that adversely affects the covered entity's or business associate's relevant electronic information systems or the confidentiality, integrity, or availability of electronic protected health information in which multi-factor authentication is infeasible and the covered entity or business associate implements reasonable and appropriate compensating controls in accordance with its emergency access procedures under paragraph (a)(2)(iii) of this section and the covered entity's or business associate's contingency plan under § 164.308(a)(13).
	(C) The technology asset in use is a device under section 201(h) of the Food, Drug, and Cosmetic Act, 21 U.S.C. 321(h) that has been authorized for marketing by the Food and Drug Administration, as follows:
	(1) Pursuant to a submission received before March 29, 2023, provided that the covered entity or business associate has deployed any updates or patches required or recommended by the manufacturer of the device.
	(2) Pursuant to a submission received on or after March 29, 2023, where the device is no longer supported by its manufacturer, provided that the covered entity or business associate has deployed any updates or patches required or recommended by the manufacturer of the device.
	(3) Pursuant to a submission received on or after March 29, 2023, where the device is supported by its manufacturer.
	(iv) Alternative measures
	—(A) Alternative measures.
	Where an exception at paragraph (f)(2)(iii) of this section applies, a covered entity or business associate must document in real-time the existence of an applicable exception and implement reasonable and appropriate compensating controls as required by paragraph (f)(2)(iv)(B) of this section.
	(B) Compensating controls.
	(1) To the extent that a covered entity or business associate determines that an exception at paragraph (f)(2)(iii)(A) or (B) or (f)(2)(iii)(C)(1) or (2) of this section applies, the covered entity or business associate must secure its relevant electronic information systems by implementing reasonable and appropriate compensating controls reviewed, approved, and signed by the covered entity's or business associate's designated Security Official.
	(2) To the extent that a covered entity or business associate determines that an exception at paragraph (f)(2)(iii)(C)(3) of this section applies, the covered entity or business associate shall be presumed to have implemented reasonable and appropriate compensating controls where the covered entity or business associate has deployed the security measures prescribed and as instructed by the authorized label for the device, including any updates or patches recommended or required by the manufacturer of the device.
	(3) To the extent that a covered entity or business associate is implementing compensating controls under this paragraph (f)(2)(iv)(B), the effectiveness of compensating controls must be reviewed and documented by the designated Security Official at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, to continue securing electronic protected health information and its relevant electronic information systems.
	(v) Maintenance.
	Review and test the effectiveness of the technical controls required by this paragraph (f) at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.
312(g)	(g) Standard: Transmission security.	312(e)	(e)(1) Standard: Transmission security.
	Deploy technical controls to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network;		Implement technical security measures to guard against unauthorized access to electronic protected health information that is being transmitted over an electronic communications network.
	and review and test the effectiveness of such technical controls at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.
			(2) Implementation specifications:
312(h)	(h) Standard: Vulnerability management
	—(1) General.
	Deploy technical controls in accordance with the covered entity's or business associate's patch management policies and procedures required by § 164.308(a)(4)(ii)(A) to identify and address technical vulnerabilities in the covered entity's or business associate's relevant electronic information systems.
	(2) Implementation specifications
	—(i) Vulnerability scanning.
	(A) Conduct automated vulnerability scans to identify technical vulnerabilities in the covered entity's or business associate's relevant electronic information systems in accordance with the covered entity's or business associate's risk analysis required by § 164.308(a)(2) or at least once every six months, whichever is more frequent.
	(B) Review and test the effectiveness of the technology asset(s) that conducts the automated vulnerability scans required by paragraph (h)(2)(i)(A) of this section at least once every 12 months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.
	(ii) Monitoring.
	Monitor authoritative sources for known vulnerabilities on an ongoing basis and remediate such vulnerabilities in accordance with the covered entity's or business associate's patch management program under § 164.308(a)(4).
	(iii) Penetration testing.
	Perform penetration testing of the covered entity's or business associate's relevant electronic information systems by a qualified person.
	(A) A qualified person is a person with appropriate knowledge of and experience with generally accepted cybersecurity principles and methods for ensuring the confidentiality, integrity, and availability of electronic protected health information.
	(B) Penetration testing must be performed at least once every 12 months or in accordance with the covered entity's or business associate's risk analysis required by § 164.308(a)(2), whichever is more frequent.
	(iv) Patch and update installation.
	Deploy technical controls in accordance with the covered entity's or business associate's patch management program under § 164.308(a)(4) to ensure timely installation of software patches and critical updates as reasonable and appropriate.
	(i) Standard: Data backup and recovery
	—(1) General.
	Deploy technical controls to create and maintain exact retrievable copies of electronic protected health information.
	(2) Implementation specifications
	—(i) Data backup.
	Create backups of electronic protected health information in accordance with the policies and procedures required by § 164.308(a)(13)(ii)(B) and with such frequency to ensure retrievable copies of electronic protected health information are no more than 48 hours older than the electronic protected health information maintained in the covered entity or business associate's relevant electronic information systems.
	(ii) Monitor and identify.
	Deploy technical controls that, in real-time, monitor, and alert workforce members about, any failures and error conditions of the backups required by paragraph (i)(2)(i) of this section.
	(iii) Record.
	Deploy technical controls that record the success, failure, and any error conditions of backups required by paragraph (i)(2)(i) of this section.
	(iv) Testing.
	Restore a representative sample of electronic protected health information backed up as required by paragraph (i)(2)(i) of this section, and document the results of such test restorations at least monthly.
	(j) Standard: Information systems backup and recovery.
	Deploy technical controls to create and maintain backups of relevant electronic information systems; and review and test the effectiveness of such technical controls at least once every six months or in response to environmental or operational changes, whichever is more frequent, and modify as reasonable and appropriate.