Characteristics of healthcare data
Healthcare laws regulate protected health information. To remain competitive and to differentiate the industry cloud, regional and local market security, privacy, and compliance regulations must be met. Microsoft Cloud for Healthcare supports common business scenarios vital to your success when data originates from various systems of record. The patterns described in the reference architecture documentation span multiple data characteristics.
The following characteristics define how the data should be ingested, persisted, and protected utilizing Microsoft Cloud for Healthcare solutions.
| Characteristic | Value and definition |
|---|---|
| Latency | Low latency: The data changes frequently and application users immediately need the changes. Changes to the data can have an impact on patient care. High latency: The data changes infrequently and application users don't need the changes immediately. Changes to the data don’t have an impact on patient care. |
| Required level | Optional: The solution is built to surface the data but isn't necessary for the entire application to be used. Usage is a customer preference, and the scenario can be configured to reflect the preference. Mandatory: The solution is built to utilize the data, and it's necessary for the application to be used. |
| PHI sensitivity | PHI sensitive: Considered protected health information. Non-PHI sensitive: Not considered to be protected health information. |
| Dataflow | Unidirectional dataflow: The data needs to be brought into the solution for users to reference the data (read-only). Bidirectional dataflow: The data needs to be transacted against by users within the solution. This action either involves creating new records or updating existing records. |
The following table uses the data characteristic definitions and applies them to Fast Healthcare Interoperability Resources (FHIR) resources used by Microsoft Cloud for Healthcare solutions.
| FHIR Resource | Acceptable data latency | Sensitivity | Care management | Home health | Patient access | Patient outreach | Patient service center | Unified patient view (administrative) | Unified patient view (clinical) | Virtual appointments |
|---|---|---|---|---|---|---|---|---|---|---|
| Allergies | Low | PHI | 🔵 | 🔵 | 🔵 | 🔵 | ||||
| Appointment | Low | PHI | 🔵 | 🔵 | 🟧 | 🟧 | 🔵 | 🔵 | 🟠 | |
| Care plans | Low | PHI | 🟧 | 🔵 | 🔵 | 🔵 | 🔵 | 🔵 | 🔵 | |
| Care teams | High | Non-PHI | 🟧 | 🟦 | 🟦 | 🟦 | 🟦 | 🟦 | 🟦 | |
| Claims | High | PHI | 🔵 | 🔵 | 🔵 | 🔵 | 🔵 | 🔵 | 🔵 | |
| Conditions | Low | PHI | 🔵 | 🔵 | 🔵 | 🔵 | ||||
| Coverages | High | PHI | 🔵 | 🔵 | 🔵 | 🔵 | 🔵 | 🔵 | 🔵 | |
| Diagnostic reports | Low | PHI | 🔵 | 🔵 | 🔵 | 🔵 | ||||
| Encounters | Low | PHI | 🔵 | 🔵 | 🔵 | 🔵 | ||||
| Episode of care | Low | PHI | 🔵 | 🔵 | 🔵 | 🔵 | ||||
| Locations | High | Non-PHI | 🔵 | 🔵 | 🟠 | 🟠 | 🔵 | |||
| Medication requests | Low | PHI | 🔵 | 🔵 | 🔵 | 🔵 | ||||
| Observations | Low | PHI | 🔵 | 🔵 | 🔵 | 🔵 | ||||
| Organizations | High | Non-PHI | 🔵 | 🔵 | 🔵 | 🔵 | 🔵 | 🔵 | 🔵 | |
| Patients | Low | PHI | 🟧 | 🟧 | 🟧 | 🟧 | 🟧 | 🟧 | 🟧 | |
| Physicians | High | Non-PHI | 🔵 | 🔵 | 🟠 | 🔵 | 🟠 | 🔵 | 🔵 | |
| Procedures | Low | PHI | 🔵 | 🔵 | 🔵 | 🔵 | ||||
| Referral requests | High | Non-PHI | 🔵 | 🔵 | 🔵 | 🔵 | ||||
| Related persons | High | PHI | 🔵 | 🔵 | 🔵 | 🔵 | ||||
| Schedules | Low | Non-PHI | 🟠 | 🟠 | ||||||
| Slots | Low | Non-PHI | 🟧 | 🟧 |
🔵 Optional, unidirectional
🟦 Optional, bidirectional
🟠 Mandatory, unidirectional
🟧 Mandatory, bidirectional
When using general-purpose cloud services, customers and partners need to define usage patterns for their data. Customers can further tailor Microsoft Cloud for Healthcare solutions to refine the data used to provide business value.
A data strategy must include the ability of your organization and partners to ingest, manage, persist, and enrich data. To facilitate industry data exchange, the strategy should also include support for open interoperability standards and data models. You might also be required to comply with industry regulations for data exchange. Standards are needed for message formats, document architecture, clinical templates, user interfaces, and patient data linkage. They might include HL7 FHIR, DICOM, X12, LOINC, SNOMED, OMOP, and CDISC standards.
The following table explains how each FHIR resource is utilized within the Microsoft Cloud for Healthcare solutions.
| FHIR resource | Resource usage |
|---|---|
| Allergies | This resource is utilized on the clinical patient view (common across all solutions) for users to reference the data. |
| Appointment EMR | This resource is utilized across solutions, and is required for patient scheduling processes. |
| Care plans | This resource is utilized on the clinical patient view. The resource is required for the patient insights measures. |
| Care teams | This resource is utilized on the clinical patient view. Users can create and modify care teams and their members. |
| Claims | This resource is utilized on the administrative patient view (common across all solutions) for users to reference the data. |
| Conditions | This resource is utilized on the clinical patient view (common across all solutions) for users to reference the data. |
| Coverages | This resource is utilized on the administrative and clinical patient view (common across all solutions) for users to reference the data. |
| Diagnostic reports | This resource is utilized on the clinical patient view (common across all solutions) for users to reference the data. |
| Encounters | This resource is utilized on the clinical patient view (common across all solutions) for users to reference the data. |
| Episode of care | This resource is accessible from the encounter form. |
| Locations | This resource is used across all the solutions, but is only required for patient scheduling. |
| Medication requests | This resource is utilized on the clinical patient view (common across all solutions) for users to reference the data. |
| Observations | This resource is accessible from the encounters form. |
| Organizations | This resource is accessible from the main application navigation and the physician form. |
| Patients | This resource is used across all the solutions and represents the core of the patient record. |
| Physicians | This resource is used across all the solutions, but is only required for patient scheduling. |
| Procedures | This resource is utilized on the clinical patient view (common across all solutions) for users to reference the data. |
| Referral requests | This resource is utilized on the clinical patient view (common across all solutions) for users to reference the data. |
| Related persons | This resource is utilized on the clinical patient view (common across all solutions) for users to reference the data. |
| Schedules | This resource is required for patient scheduling. |
| Slots | This resource is required for patient scheduling. As part of the scheduling, this resource requires updates to get written back to the source. |