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.