다음을 통해 공유


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.