Search
K
< Back

Overview

Patient360 provides a complete, longitudinal view of a patient’s clinical history by retrieving, normalizing, and reconciling data from external networks and systems including Carequality, eHealth Exchange (eHX), CommonWell, and TEFCA. The solution applies identity resolution, deduplication, and data normalization to produce a unified FHIR record that supports clinical decision-making, intake workflows, care coordination, and population health initiatives.

Identity Resolution

Before retrieving records, Health Gorilla applies both deterministic and probabilistic matching algorithms to resolve the patient’s identity across external systems. This two-stage process helps ensure that data returned belongs to the correct individual.

  • Patient discovery: The system identifies candidate matches across networks and vendors using transactions such as $cw-search.
  • Record linkage: Once matches are found, Health Gorilla applies strict linking logic—via $cw-enroll or preconfigured identity rules—to associate incoming records with a single, unified patient identity in your environment.

Matching logic is configurable and can be tuned based on your operational or clinical requirements.

Data Aggregation

Patient360 retrieves both structured and unstructured data from a wide range of external systems. This data is collected through Health Gorilla’s network integrations and processed into a consistent format for use in downstream workflows.

  • Structured data: Includes FHIR resources such as Patient, Encounter, Observation, MedicationStatement, and Condition.
  • Unstructured documents: Includes clinical summaries, CCDA documents, imaging reports, and other narrative records retrieved as DocumentReference and Binary resources.

All incoming data is staged for transformation and reconciliation.

Normalization and Deduplication

Once records are retrieved, Health Gorilla transforms the data to conform to FHIR standards, maps it to consistent terminologies, and eliminates redundant content.

  • FHIR transformation: All records are converted to the target FHIR version, either R4 (preferred) or STU3 (legacy support).
  • Terminology mapping: Clinical concepts are mapped to standard coding systems, such as LOINC (for labs), SNOMED CT (for problems and procedures), RxNorm (for medications), and ICD-10.
  • Deduplication: Redundant entries across multiple documents or sources are merged or suppressed to improve clarity and prevent data inflation.

These processes ensure the final dataset is clean, standardized, and clinically actionable.

FHIR Bundle Delivery

The final output is a FHIR Bundle resource that contains the patient’s external record. This bundle serves as the basis for clinical integration, analytics, or downstream processing.

  • Resource format: The bundle contains FHIR R4 (preferred) or STU3 (legacy support) resources, depending on your implementation environment.
  • Document references: Links to original clinical documents are included as DocumentReference and Binary resources.
  • Metadata: Each resource includes provenance tags and matching confidence indicators where applicable.

Clients can extract specific resources via FHIR queries or download the entire bundle for ingestion.

Operational Considerations

Patient360 is typically invoked using the $p360-retrieve operation. The retrieval process is asynchronous and may take time to complete, depending on the number of sources and network response times.

  • Requires patient enrollment: The patient must have a valid FHIR ID in your environment and be enrolled using identity matching tools.
  • Response timing: Record retrieval duration varies by data volume and network responsiveness.
  • Follow-up actions: Clients can optionally use $everything (for legacy STU3 implementations) or $export-ccda to format or filter the output.