Monitor service health and compliance in a patient portal

Disclaimer

This guide is intended for informational purposes only and does not constitute legal advice. While every effort has been made to ensure the accuracy of the information provided, it is recommended that you consult with a qualified legal professional to ensure compliance with all applicable laws and regulations.

In this healthcare use case, an organization sells self-administered medical tests to patients. Patients can use the online patient portal to order the tests, report their test results, and receive medical advice from a healthcare professional based on the results and data stored in the app.

The user flow includes the following steps for the patient portal use case:

  1. Create an account/log in.
  2. Order a test.
  3. Pay/confirm the test.
  4. Confirm receiving the test.
  5. Enter test results.
  6. Wait for the doctor’s advice based on the test results.

As this service provider handles and processes technical information, personal customer data, and electronic health records, it is important to process data in compliance with all regulations and laws.

Log data is generated in various systems and processed in Dynatrace for multiple scenarios in this use case. To prevent unauthorized users from seeing the data that they aren’t supposed to, sensitive elements of the collected data need to be masked or protected with access restrictions at storage level.

Steps to consider to protect sensitive data and address your compliance requirements

You may be subject to regulation or compliance if your logs contain personal information or other sensitive data. Dynatrace typically doesn’t require such personal data to provide value.

Start with reviewing the data that your logs collect. In this patient portal use case, this could include information such as user’s IP address, email address, credit card number, or social security number. While this information may be necessary for certain use cases, decide whether you actually need this information for your specific purpose. Check whether your organization has guidelines on protecting sensitive data that you can use.

Key terms

Gain a deeper understanding of the different types of masking used in Log Management and Analytics compliance.

At-capture masking requires identifying and masking sensitive parts of your log records before data is transferred to Dynatrace. To achieve this, you can choose OneAgent to collect your logs. OneAgent has a built-in mechanism for sensitive data masking that can be granularly configured on the host, host group, or environment level.

For details, refer to Mask your logs at capture or Protect personal data by not capturing it (masking at capture).

When masking at storage is implemented, data is sent to the Dynatrace server for optimal analysis and is masked before it's stored.

For details, refer to Protect personal data by not storing it (masking at storage).

When data is masked at display, it's stored in its original form but is accessible only to the users of your choice.

For details, refer to Protect personal data by not displaying it (masking at display).

With this method, you can mask the data once it reaches Dynatrace, by setting log processing rules. After data is processed, it is sent to storage and is available for further analysis. The key advantage of this method is the fact that it allows data flow from all log ingest channels.

For details, refer to Mask your logs at ingest.

Scenario 1

As an ITOps professional, you need to make sure the app is running smoothly and the user can go through the described user flow without issues.

In this scenario, the user is responsible for processing or analyzing logs about user transactions to monitor operations of the patient and ensure that it’s up and running.

Log example from online patient portal

Personal information contained in logs and methods of masking it

The table below lists some of the personal information that a log line might include. It provides a link to the documentation that describes how to either mask the data, control access to this data, or help meet your compliance requirements in another way.

Data Type
Needed for the use case
Actions/mitigation
Learn more
Patient ID
No
Do not capture using Mask at-capture capabilities.
Patient email
No
Do not capture using Mask at-capture capabilities.
Credit Card Number
No
Do not capture using Mask at-capture capabilities.
Credit Card CVV
No
Do not capture using Mask at-capture capabilities.
Credit Card expiration date
No
Do not capture using Mask at-capture capabilities.
Activity log (without identifiers)
Yes
No action required; will appear in the log line.
Transaction ID
Yes
No action required; will appear in the log line.

Scenario 2

As a compliance officer, you need to make sure all access events to medical datasets are logged and handled appropriately.

In this scenario, the compliance officer has to ensure that the sensitive data in logs isn’t accessible to unauthorized users but is available for audit purposes as needed.

Example of raw data

Source data from medical dataset audit trail

The table below lists some of the personal information that a log line might include and provides a link to the documentation that describes how to either mask the data, control access to this data, or help meet your compliance requirements in another way.

Data Type
Log record field name
Needed for the use case
Actions/mitigation
Learn more
Patient ID
Affected.patient patient_id
Yes
Apply proper retention periods and access controls for protecting PII.
Case ID
Affected.case
Yes
Apply proper retention periods and access controls for protecting PII.
Doctor ID
actor.id
Yes
Apply proper retention periods and access controls for protecting PII.
Doctor Name
actor_name
No
Do not capture using Mask at-capture capabilities.
Company of Doctor
actor_company
No
Do not capture using Mask at-capture capabilities.
Employee status of Doctor
actor_type
No
Do not capture using Mask at-capture capabilities.
Action
action
Yes
No action required; will appear in the log line.
Action timestamp
date
Yes
No action required; will appear in the log line.
Action ID
id
No
Do not capture using Mask at-capture capabilities.
Medical test ID
affected_case
No
Do not capture using Mask at-capture capabilities.
Medical test type
affected.test_type and affected.test_name
No
Do not capture using Mask at-capture capabilities.

Example of sanitized data

The screenshot below shows how the ingested logs can look after some of the actions described in the table above are applied.

Sanitized data in Dynatrace