Skip to main content
Version: Next

Data Curation, Validation, and Supported FHIR Resources

HL7 Engine

The Centaur® Data Platform's HL7 Engine routes HL7 ORM(Order) messages from Athena to JCI and Sectra and HL7 ORU(Results) messages from JCI to Sectra and Athena. It uses the MLLP protocol. The engine reprocesses the message if it fails to send it to the destination or if there is any other exception apart from the valid rejects, i.e., ACK returns as AE (Application Error) or AR (Application Reject).

  • The engine stores files as source/success or source/error for source requests.
  • The engine stores files as destination/success or destination/error for destination requests.

ORM(Order) Message End to End Validation

HL7 Engine Retry Logic

The retry logic begins for all failed messages except valid rejects, i.e., ACK returns as AE or AR. The HL7 engine will retry for the first attempt after 2 seconds. If it fails, it stores the message in the folders mentioned below. When a message is put under the “retry” folder (or subfolders), it will be deleted from this location after a successful retry.

  1. Error Folder - <container_name>/<destination>/error/<year>/<month>/<date>/<messageid>.hl7
  2. Retry Folder - <container_name>/retry/1_min/<messageid>_<destination_name>.hl7
Scheduler RunningProcessing DirectoryMax AttemptsNext Directory
Every 1 Minuteretry/1_min5retry/5_min
Every 5 Minuteretry/5_min3retry/15_min
Every 15 Minuteretry/15_min2retry/1_hr
Every 1 Hourretry/1_hr24retry/error

Note: If reprocessed successfully, messages will be deleted from the “retry” folder, and the success message will be created in the destination “success” directory.

ORM(Order) Message End to End Validation

Source Data Processing

The Centaur® Data Platform's pipelines process source data every day from sources such as New Direction, Facets, Enterprise Data Warehouse (EDW), Athena, and Altruista Guiding Care.

SourcesFormatSource LocationDestination Location
FacetsCSVrawzone/CDH_FACETScont-fhir-convertor/Facets
EDWCSVrawzone/CDH_EDWcont-fhir-convertor/EDW
New DirectionFHIR JSONrawzone/CDH_NEWDIRECTIONcont-fhir-convertor/NewDirection
Altruista Guiding CareDatabaserawzone/CDH_GUIDINGCAREcont-fhir-convertor/GuidingCare
Athena HPDECCDA, CSVrawzone/CDH_ATHENAcont-fhir-convertor/Athena

Historical Data Processing

The previous system’s endpoint is used to export historical FHIR bundle data, which is then leveraged by the Centaur® Data Platform and divided into individual resource types for each bundle. Centaur® Data Platform’s bulk data import is set up to work, and it can quickly ingest all the historical data within minutes. A trigger is used to commence Bulk Importing, which involves taking multiple FHIR bundles at a time and importing them to the FHIR server.

Member Record Processing

Centaur® Data Platform’s convertor reads the source data from the storage for the conversion process. During conversion, the platform verifies whether the file has. hl7, .xml, and .json extension. The convertor will generate a list of resources from the FHIR R4 specification for a particular source file. Below is the list of generated resources:

  1. Account
  2. AllergyIntolerance
  3. CarePlan
  4. CareTeam
  5. Communication
  6. Condition
  7. Coverage
  8. Device
  9. DiagnosticReport
  10. DocumentReference
  11. Encounter
  12. EpisodeOfCare
  13. FamilyMemberHistory
  14. Goal
  15. Immunization
  16. Location
  17. Medication
  18. MedicationRequest
  19. MedicationStatement
  20. MessageHeader
  21. Observation
  22. Organization
  23. Patient
  24. Practitioner
  25. PractitionerRole
  26. Procedure
  27. Provenance
  28. RelatedPerson
  29. ServiceRequest

Centaur® Data Platform has a built-in FHIR data mapper, which uses predefined templates to transform data from various formats into FHIR R4 bundles. These templates consist of specific mapping rules that dictate how data elements from the source format should be placed within the FHIR R4 structure. Mapping templates can be saved, reused, and easily integrated with other systems and tools – drastically reducing timelines associated with the mapping process.

In the intricate landscape of healthcare data interoperability, converting clinical data (like HL7 ADT, CCDA, XML, JSON, etc.) into FHIR R4 resources is a critical step. Centaur® Data Platform assures that no data is lost in translation, ensuring that every element finds its place in the resulting FHIR R4 resource.

Curation and Validation of Member Records in FHIR Server

The Centaur® Data Platform uses a curation process to retrieve unique identifiers mapped to specific source files and the FHIR resource IDs for each FHIR resource. This process is enabled by two configuration files: resourceConfig and sourceConfig, which have all the info related to resource identifiers and source-related configurations. These files can be customized based on source format or business needs.

The resourceConfig file contains all the unique identifiers based on the source and FHIR resource and is used only if the mapping attribute present in sourceConfig is set to identifier; otherwise, it will be a direct ID search with the FHIR server without any identifiers being used. Meanwhile, the sourceConfig file contains priority lists with primary and secondary sources and registry templates based on source. These unique identifiers can then fetch the unique ID from the FHIR server.

Apart from the identifier configurations, sourceConfig will contain another set of EMPI configurations containing all the necessary information about the EMPI Processor.

For resources such as Patient / Organization / Practitioner, the unique FHIR resource ID will be replaced with the help of the EMPI Module, which is done through an API call.

During the Validation process, the Centaur® Data Platform checks the Implementation Guide (IG) Validation to validate incoming resources. The platform also follows the HL7 FHIR specifications, which help validate the structure, cardinality, value domains, and coding / codeable concept bindings of the resource.

In the Reference Handler component of the Centaur® Data Platform, references from FHIR resource data are verified using identifiers, and a valid FHIR ID is updated for each reference from the FHIR server.

As mentioned in the curation process, the platform uses the resource identifiers retrieved from the resourceConfig to search for unique identifiers in the FHIR Server if the mapping is set to identifier else if the mapping is ID, then a direct call to the FHIR server is made using a resource type and resource ID without using any identifiers. Based on the FHIR ID present in the JSON, the message is inserted or updated into the FHIR Server.

The Retry Reference Handler feature of the Centaur® Data Platform will keep searching and processing references in the FHIR resource until it reaches the maximum retry count of 6. If the reference is found and replaced during the retry process, the FHIR resource will be updated accordingly.

HL7 FHIR Resources Supported

Centaur® Data Platform v3.1.3 supports USCDI V3 and FHIR R4 Standards

United States Core Data for Interoperability (USCDI) | Interoperability Standards Advisory (ISA) (healthit.gov)

HL7.FHIR.US.CORE\USCDI - FHIR v4.0.1