How to Integrate PGx Data with eClinicalWorks

The most effective eClinicalWorks PGx integration combines HL7 v2 ORU messaging for authoritative lab result ingestion with discrete FHIR Genomics Observations for structured data persistence, and CDS Hooks or SMART on FHIR for prescribing-time decision support. Your two developer entry points are Eclinicalworks for provider-facing and backend FHIR APIs, and connect4.healow.com for patient-facing flows through Healow. A middleware translation layer, per-practice API activation, and sandbox validation are required before any production rollout.

The reason this hybrid approach works is that eClinicalWorks' FHIR support centers on US Core profiles, which cover the common read-heavy and patient-facing use cases well but do not natively handle the full complexity of PGx result structures. HL7 v2 ORU messages remain the authoritative transport for lab results, ensuring genotype and phenotype data lands in the correct Results section of the chart. FHIR Genomics Observations then give you the discrete, coded layer that CDS Hooks and SMART on FHIR apps can query at prescribing time. Platforms like SignalPGx are built to deliver exactly this combination, with discrete Observation writes, living reanalysis, and a medical-director review workflow that satisfies clinical governance requirements.

Key Takeaways

A successful eClinicalWorks PGx integration requires HL7 v2 ORU for authoritative result ingestion, discrete FHIR Observations for CDS-queryable data, and CDS Hooks for prescribing-time alerts, with per-practice API activation planned from the start.

This article is general information, not a substitute for advice from a qualified doctor. Consult a qualified healthcare professional about your own circumstances before acting on anything here.

Table of Contents

• How does eClinicalWorks PGx integration work across different methods?
• How should you map PGx results into eClinicalWorks fields?
• Where do you start with eClinicalWorks developer portals and APIs?
• How do you surface PGx guidance at the moment of prescribing in eClinicalWorks?
• What transport options do labs use to send PGx results to eClinicalWorks?
• What does a solid QA checklist look like before going live?
• What are the most common eClinicalWorks PGx integration problems?
• How does SignalPGx handle eClinicalWorks integration in practice?
• What compliance requirements apply to PGx data exchange with eClinicalWorks?
• What should your team do next?
• Developer and standards resources for this integration
• The fastest safe path to production is not the most obvious one
• SignalPGx accelerates your eClinicalWorks PGx deployment
• Sources
• FAQ

How does eClinicalWorks PGx integration work across different methods?

Choosing the right transport and runtime depends on whether your primary goal is authoritative result ingestion, structured data persistence, provider-facing UI, or real-time prescribing alerts. Each method has a distinct role, and most production implementations use at least two of them together.

When to use each method. HL7 v2 ORU is the right choice when a clinical lab needs to push authoritative PGx results into the chart and have them appear in the Results section exactly as any other lab result would. FHIR Genomics Observations are the right choice when you need discrete, queryable data that CDS logic can act on, rather than a PDF attachment a clinician must open manually. SMART on FHIR apps suit provider- or patient-facing interfaces that need a richer UI than an alert card can provide. CDS Hooks is the right choice when the goal is surfacing a PGx recommendation at the exact moment a clinician selects a medication, without requiring them to navigate away from the prescribing workflow.

One trade-off worth planning for: FHIR Observation writes persist discrete data in the chart, but reanalysis updates (when guidelines change) require a mechanism to update or supersede existing Observations. HL7 v2 ORU handles this through corrected result messages; FHIR requires explicit versioning or a replacement Observation with a replaces reference. Both paths are manageable, but neither is automatic.

How should you map PGx results into eClinicalWorks fields?

Mapping PGx outputs to the right eCW structures determines whether results are searchable, whether CDS can act on them, and whether clinicians find them where they expect.

The primary mapping targets are:

• FHIR Observation for discrete genotype and phenotype results, using LOINC codes for each observation (e.g., LOINC 51969-4 for genetic analysis summary, gene-specific LOINC codes for CYP2C19, CYP2D6, and related loci).
• DocumentReference for the full PDF report, attached to the patient record as a binary attachment with a LOINC document type code.
• eCW Results section as the landing zone for HL7 v2 ORU messages, where OBX segments carry discrete values and NTE segments carry narrative.
• Flowsheets for longitudinal tracking of phenotype assignments across multiple gene panels.
• Medication list flags or Problem/Condition entries for persistent prescribing warnings tied to specific drug-gene pairs.

For code systems, LOINC is the required standard for PGx observations in FHIR and HL7 v2. HGVS notation applies when you need to represent specific variant identifiers. PharmVar allele nomenclature (e.g., CYP2C19*2) is appropriate for star-allele diplotype fields in Observation.valueCodeableConcept. Avoid relying solely on local lab codes; canonicalize to LOINC before writing to eCW to avoid mapping drift over time.

A concrete mapping example: a CYP2D6 poor metabolizer result maps as an Observation with Observation.code set to the LOINC code for CYP2D6 gene panel, Observation.valueCodeableConcept set to the SNOMED or local phenotype term for "poor metabolizer," and a linked DocumentReference carrying the full signed report PDF. The recommendation itself maps to a separate Observation or a flag on the relevant medication order, depending on whether your CDS layer reads from FHIR or from eCW's native alert system.

Pro Tip: Prefer discrete coded Observations over PDF-only attachments whenever your CDS layer needs to act on the data. A PDF is useful for the clinician reading the full report, but a CDS Hooks service cannot parse a PDF at prescribing time. Write the discrete Observation first, attach the PDF as a DocumentReference second.

eClinicalWorks' interoperability surfaces support both HL7 v2 ORU and FHIR R4, but complex PGx signals often require HL7 v2 ORU mappings to ensure results persist in the correct lab and results locations, particularly when US Core FHIR profiles do not cover the full depth of genomic data structures your lab produces.

Where do you start with eClinicalWorks developer portals and APIs?

eClinicalWorks exposes two distinct API surfaces, and knowing which one to use for which flow saves significant scoping time.

• fhir.eclinicalworks.com is the entry point for provider-facing and backend FHIR R4 APIs, including bulk FHIR exports and Observation writes. This is where PGx lab systems and middleware connect for discrete data ingestion and provider-scoped queries.
• connect4.healow.com is the developer portal for patient-facing integrations through Healow, eClinicalWorks' patient engagement platform. Patient-scoped FHIR queries, patient portal apps, and consumer-facing PGx report delivery flow through this surface.

eClinicalWorks' certified APIs are available to third-party developers, but production access is per practice, enabled through On-Demand Activation. Plan for this during scoping: you cannot assume a single tenant-level credential grants access across all practices in a health system. Each practice must independently activate the API connection, which affects your rollout timeline and your testing plan.

Authentication follows OAuth 2.0 throughout. SMART on FHIR launch patterns apply for both patient and provider contexts:

• Patient launch: initiated from Healow, scoped to the authenticated patient's record, using patient/*.read scopes appropriate to the data types your app needs.
• Provider (EHR) launch: initiated from within the eCW clinical UI, scoped to the provider's session, using user/*.read or user/*.write scopes depending on whether your app writes Observations back to the chart.
• Backend (system) launch: used for lab-to-EHR batch writes and middleware sync, using client credentials flow with pre-authorized system scopes.

For HL7 v2 MLLP connections, eClinicalWorks supports MLLP over TLS for lab result ingestion. Your network team needs to provision a dedicated MLLP listener endpoint, and the lab's interface engine must be configured to send ORU messages to that endpoint. Test this connection in the sandbox environment before requesting production credentials.

Pro Tip: Request sandbox credentials early. eCW sandbox provisioning can take days to weeks depending on the practice and partner tier. Starting the sandbox request in parallel with your mapping design work, rather than sequentially, keeps the overall timeline on track.

How do you surface PGx guidance at the moment of prescribing in eClinicalWorks?

Getting PGx data into the chart is only half the problem. The harder challenge is making sure clinicians see the relevant recommendation at the exact moment they are selecting a medication, not buried in a results tab they may not check.

Three patterns are available in eClinicalWorks, each with different visibility and implementation requirements:

• Native clinical inbox alerts (the "L" jellybean): eClinicalWorks' precision medicine partner program supports genomic decision support that surfaces directly in the clinical inbox and as in-workflow alerts. This mechanism delivers strong in-workflow visibility because it appears in the provider's native eCW interface without requiring a separate app launch. Accessing it typically requires established partner status with eClinicalWorks.
• CDS Hooks (external service): A CDS Hooks service receives a hook call from eCW at the order-sign or medication-prescribe hook point, evaluates the patient's PGx profile against the proposed medication, and returns an alert card with a recommendation, a strength-of-evidence label, and a link to the full report. This approach works without partner status and gives you full control over the recommendation logic. The trade-off is that the alert card appears as an external suggestion rather than a native eCW alert, which can affect clinician attention.
• SMART on FHIR app (embedded UI): A SMART app launched from within the eCW prescribing workflow can display the full PGx report, the medication intelligence graph, and gene-drug interaction details in a panel alongside the prescribing screen. This gives the richest UI but requires the clinician to actively launch the app, making it better suited as a reference tool than a passive alert.

CDS Hooks adoption reduces reliance on document-based lab results and improves the likelihood that clinicians encounter PGx guidance at the prescribing moment. For most implementations, the practical recommendation is to deploy CDS Hooks for passive prescribing-time alerts and a SMART on FHIR app for on-demand detailed review, using the native partner alert channel when partner status is available.

Alert design matters as much as the delivery mechanism. Keep CDS Hooks cards to one or two sentences, include the CPIC or FDA evidence grade, and link directly to the full report rather than repeating its content in the card. Alert fatigue is a real operational risk; a card that fires for every gene-drug pair regardless of clinical significance will be dismissed or disabled within weeks of go-live.

What transport options do labs use to send PGx results to eClinicalWorks?

Labs transmit PGx results through three main channels, and your integration architecture needs to handle all three if you are working with multiple reference labs or a heterogeneous lab network.

eClinicalWorks supports HL7 v2 ORU messaging for lab result ingestion, and this remains the most reliable transport for attaching PGx results to the patient record in a way that appears in the correct Results section. Batch SFTP feeds are common for high-volume reference labs that process results overnight; they require a scheduled ingest job and a reconciliation step to match results to the correct patient and encounter.

For ORU messages, the critical fields are: MSH (message header with sending lab OID), PID (patient identifiers, including MRN and date of birth for matching), OBR (observation request, referencing the PGx panel order), and OBX (individual observations for each gene result, phenotype assignment, and recommendation). Each OBX must carry a valid LOINC code in OBX-3; local lab codes in OBX-3 without a LOINC translation will not map correctly to eCW's results display or to downstream FHIR Observations.

Edge cases to plan for: batch reanalysis updates (when a lab reprocesses a sample against updated guidelines) require a corrected ORU with the appropriate result status code. Duplicate suppression logic must compare incoming ORU messages against existing results by accession number and result date to avoid creating duplicate chart entries. Patient identifier mismatches, particularly when a lab uses a different MRN namespace than the practice, require a master patient index (MPI) lookup or a configurable identifier mapping table in your middleware.

What does a solid QA checklist look like before going live?

A structured validation plan prevents the most common production failures: results landing in the wrong chart location, CDS alerts not firing, and duplicate entries accumulating after reanalysis updates.

1. Unit tests: Validate ORU message parsing against a library of synthetic test messages covering normal results, corrected results, and edge-case LOINC codes. Confirm that each OBX segment maps to the expected eCW field and that LOINC codes resolve correctly.
2. FHIR write/read round-trips: Write a synthetic Observation to the eCW sandbox, read it back, and confirm that the resource ID, LOINC code, value, and patient reference are preserved without modification.
3. End-to-end clinical scenario: In the sandbox, prescribe a medication with a known gene-drug interaction for a synthetic test patient who has a PGx result on file. Confirm that the CDS Hooks card fires, displays the correct evidence grade, and links to the correct report.
4. Reanalysis update test: Send a corrected ORU for an existing result and confirm that the updated result supersedes the original without creating a duplicate chart entry.
5. Alert wording sign-off: Have a clinician (or your medical director) review the exact text of each CDS Hooks card and approve the wording before production deployment.
6. Audit trail verification: Confirm that every PGx result write, every CDS alert trigger, and every clinician acknowledgment is logged with a timestamp and user identifier in the eCW audit trail.
7. Security and transport validation: Confirm MLLP over TLS is active, OAuth 2.0 tokens are scoped correctly, and no PHI is transmitted over unencrypted channels.

Pro Tip: Version-control your LOINC mapping tables in a source code repository alongside your interface engine configuration. When a lab updates its result codes or a new gene panel is added, a versioned mapping table makes the change auditable and reversible without touching production configuration directly.

A middleware sync layer that centralizes mapping rules, handles retries, and monitors inbound message statistics makes this checklist significantly easier to execute and maintain over time.

What are the most common eClinicalWorks PGx integration problems?

Most integration failures fall into a small set of repeatable patterns, and most have straightforward fixes once you know what to look for.

• ORU fields mapped to wrong observation codes: The most frequent cause is a lab sending local proprietary codes in OBX-3 without a LOINC translation. Fix: require LOINC codes in OBX-3 as a lab onboarding requirement, or add a translation table in your middleware that maps local codes to LOINC before the message reaches eCW.
• Attachments only, no discrete data: Some labs send PGx results as a single PDF embedded in an ORU NTE segment, with no discrete OBX observations. The result lands in the chart as a document but cannot trigger CDS. Fix: negotiate with the lab to add discrete OBX segments, or parse the PDF in middleware and generate synthetic Observations from the extracted data.
• CDS alerts not visible in the provider workflow: A CDS Hooks service that is correctly configured but not registered with the eCW instance will not fire. Fix: confirm the CDS Hooks endpoint URL is registered in the eCW configuration, and verify that the hook type (order-sign vs medication-prescribe) matches what eCW fires.
• Patient identifier mismatches: A lab using a different MRN namespace than the practice will produce ORU messages that cannot be matched to a patient record. Fix: implement an MPI lookup in your middleware, or configure a cross-reference table that maps lab patient IDs to eCW patient IDs.
• Per-practice activation gaps: A production credential that works for one practice will not automatically work for another. Fix: build per-practice activation into your deployment checklist and track activation status for each practice in your rollout tracker.

For ongoing operations, monitor inbound ORU message statistics (volume, error rate, and unmatched patient rate) and set up alert-usage analytics to track CDS card acceptance and dismissal rates. A dismissal rate above roughly 80% on any single card is a signal that the alert is firing too broadly or the wording needs revision.

How does SignalPGx handle eClinicalWorks integration in practice?

SignalPGx is built to deliver the full integration stack described in this guide, with the clinical governance layer that most in-house builds underestimate.

On the data side, SignalPGx writes discrete FHIR Observations for genotype and phenotype results, attaches the full signed report as a DocumentReference, and supports HL7 v2 ORU delivery for labs that need authoritative result ingestion into the eCW Results section. The PGx pipeline from genotype to guidance is automated, drawing on evidence from more than 20 sources including CPIC, FDA biomarker labeling, and DPWG to generate graded recommendations.

Key capabilities relevant to eClinicalWorks integration:

• Discrete Observation writes with LOINC-coded genotype and phenotype fields, ready for CDS Hooks consumption.
• Medication intelligence simulation that evaluates a patient's full medication list against their PGx profile, not just individual drug-gene pairs in isolation.
• Living reanalysis that reprocesses existing results when CPIC or FDA guidelines are updated, with corrected result delivery back to the EHR.
• Medical-director review workflow with a full audit trail, satisfying clinical governance and CLIA requirements before any report reaches the clinician or patient.
• White-label infrastructure that lets your lab deploy under its own brand, typically within 5–7 days for report enablement.

A typical integration timeline with SignalPGx runs as follows: sandbox credential request and API mapping design in week one; HL7 v2 ORU and FHIR Observation test phase in weeks two and three; clinical validation with synthetic test patients and medical-director sign-off in week four; production activation per practice from week five onward. The exact duration depends on the number of practices, the lab's existing interface engine capabilities, and the complexity of the gene panel.

Security and compliance are handled at the infrastructure level. SignalPGx operates under HIPAA-compliant data handling with BAAs available for all integration partners, supports HL7 and FHIR over secure transports, and maintains a complete audit trail for every medical-director review and every recommendation delivered to the EHR.

What compliance requirements apply to PGx data exchange with eClinicalWorks?

Three compliance areas require explicit planning before production: ONC certification, HIPAA, and clinical governance.

• ONC Certified Health IT: eClinicalWorks' certified API surfaces are listed on the ONC Certified Health IT Product List (CHPL). Third-party developers connecting to these APIs must use the certified endpoints and cannot circumvent the certified API layer for data exchange that falls within the ONC certification scope. Confirm that your integration uses only certified API surfaces and that your application is registered appropriately.
• HIPAA and PHI handling: Genomic data is PHI under HIPAA. All data in transit must use encrypted transports (TLS 1.2 or higher for HTTPS and MLLP over TLS). BAAs are required between the lab, the integration middleware vendor, and any cloud infrastructure handling PHI. PHI minimization applies: do not transmit more genomic data than is required for the clinical use case.
• Patient consent for genomic data: Some states impose additional consent requirements for genetic testing beyond standard HIPAA authorization. Confirm your legal team has reviewed applicable state law for each practice jurisdiction before production deployment.
• Clinical governance: Document medical-director sign-off on the CDS alert wording and the evidence grading methodology. Preserve audit trails for every PGx recommendation delivered to the EHR, including the guideline version and the date of delivery. Establish a reanalysis policy that defines how often results are reprocessed against updated guidelines and how updated recommendations are communicated to clinicians.

eClinicalWorks' precision medicine partner program provides a structured path for genomic decision support vendors to surface alerts within the eCW UI, which can simplify the compliance review by using a vetted integration channel rather than a custom third-party FHIR app.

What should your team do next?

The fastest path to a production-ready eClinicalWorks PGx integration follows this sequence:

1. Enable eClinicalWorks FHIR APIs and request sandbox credentials via fhir.eclinicalworks.com for provider/backend flows and connect4.healow.com for patient-facing flows. Confirm per-practice activation requirements with your eCW account team before finalizing your rollout plan.
2. Design your LOINC mapping table for every gene panel your lab reports. Map each genotype result, phenotype assignment, and recommendation to the correct LOINC code and eCW field before writing a single line of interface engine configuration.
3. Ingest authoritative PGx results via HL7 v2 ORU for the Results section, and write discrete FHIR Observations in parallel for CDS consumption. Do not rely on PDF attachments alone.
4. Prototype CDS Hooks with a test endpoint that returns a static card for a known gene-drug pair. Validate the hook fires correctly in the eCW sandbox before building the full recommendation logic.
5. Run the full QA checklist with synthetic test patients, including reanalysis update tests and clinician sign-off on alert wording, before requesting production activation for any practice.

Developer and standards resources for this integration

The following resources are the primary reference points for implementation teams:

• eClinicalWorks developer portals: Eclinicalworks for provider/backend FHIR R4 APIs; connect4.healow.com for patient-facing Healow APIs.
• HL7 FHIR Genomics: The HL7 Clinical Genomics Work Group publishes the FHIR Genomics Implementation Guide, which defines Observation profiles for genotype, haplotype, and phenotype results. Use this as the reference for Observation resource structure.
• CDS Hooks specification: cds-hooks.org publishes the current specification, including hook definitions for order-sign and medication-prescribe. The CDS Hooks for PGx overview from the Great Lakes Health System Network provides a practical PGx-specific implementation reference.
• LOINC PGx codes: The Regenstrief Institute maintains LOINC codes for genetic observations at loinc.org. Search the LOINC database for gene-specific panel codes and individual observation codes before finalizing your mapping table.
• ONC Certified Health IT Product List: The CHPL at healthit.gov lists all ONC-certified products and their certified API capabilities. Confirm eClinicalWorks' current certification status and API scope before finalizing your compliance documentation.
• CPIC and FDA PGx guidance: cpicpgx.org for CPIC gene-drug guidelines and fda.gov/drugs for FDA Table of Pharmacogenomic Biomarkers in Drug Labeling. Both are required references for evidence grading in CDS cards.
• SMART on FHIR reference: smarthealthit.org for the SMART App Launch Framework specification and reference implementations.
• Middleware and sync tooling: A managed middleware layer that handles FHIR-to-HL7 translation, retries, and real-time sync reduces long-term operational overhead compared with custom point-to-point interfaces.
• SignalPGx technical resources: The PGx EHR integration guide on the SignalPGx blog covers FHIR and CDS Hooks implementation patterns in detail. For guideline source selection, the CPIC, FDA, and DPWG comparison post explains how evidence grades map to CDS card content.
• AI-assisted integration approaches: For teams evaluating AI-enabled clinical integrations and advanced medication intelligence, the life sciences AI integration overview covers value propositions relevant to PGx interpretation workflows.

The fastest safe path to production is not the most obvious one

The conventional advice for EHR integration projects is to start with FHIR because it is the modern standard and the path of least resistance for new development. For PGx specifically, that advice leads teams into a predictable trap.

eClinicalWorks' FHIR R4 support is solid for US Core profiles, but PGx data structures go well beyond US Core. A team that builds a FHIR-only integration discovers, usually in the QA phase, that their discrete Observations are not appearing in the Results section where clinicians expect lab results, that their CDS Hooks service is firing but the cards are being dismissed because they lack the clinical context a well-structured ORU message would have provided, and that their reanalysis update logic has no clean mechanism to supersede existing Observations without creating duplicates.

The right starting point is HL7 v2 ORU for authoritative result ingestion, with FHIR Observations written in parallel as the CDS-queryable layer. This is not a compromise; it is the architecture that matches how eClinicalWorks actually processes lab results. The ORU message lands in the Results section with full clinical context. The FHIR Observation gives the CDS Hooks service a structured, queryable record. Neither replaces the other.

The second underestimated factor is per-practice API activation. Teams that scope a multi-practice rollout assuming a single credential grants access to all practices will hit delays at production that could have been planned for during scoping. Build per-practice activation into your project plan as a tracked deliverable, not an afterthought.

Finally, the clinical governance layer is where most in-house builds run short. Medical-director sign-off on alert wording, a reanalysis policy, and an audit trail for every recommendation delivered to the EHR are not optional compliance checkboxes. They are the difference between a PGx integration that clinicians trust and one they disable after the first month. A platform like SignalPGx that includes the clinical-review workflow and living reanalysis as core infrastructure removes that burden from your team entirely.

SignalPGx accelerates your eClinicalWorks PGx deployment

Labs and health systems that have mapped the integration architecture above still face a significant build: discrete Observation writes, HL7 v2 ORU ingestion, CDS Hooks service logic, living reanalysis, and a medical-director review workflow are each non-trivial to build and maintain in-house. SignalPGx delivers all of it as a white-label reporting infrastructure your lab deploys under its own brand.

The white-label PGx reporting platform includes FHIR/HL7 integration support, a medication intelligence graph that evaluates full polypharmacy profiles against PGx results, living reanalysis that reprocesses results as CPIC and FDA guidelines evolve, and a medical-director review workflow with a complete audit trail. White-label report enablement typically takes 5–7 days. HIPAA compliance and BAA coverage are standard. SignalPGx has direct experience with eClinicalWorks integration, including the per-practice activation requirements and the HL7 v2 ORU mapping patterns that make results land correctly in the chart. To discuss your integration scope and timeline, book a demo with the SignalPGx team.

Sources

• Certified EHR Technology - eClinicalWorks
• eClinicalWorks Integrations: FHIR, HL7 & Sync Guide
• eClinicalWorks Integration Guide: V11, FHIR, Healow & HL7 v2

FAQ

Does eClinicalWorks have an API?

Yes. eClinicalWorks exposes certified FHIR R4 APIs via fhir.eclinicalworks.com for provider and backend use cases, and patient-facing APIs via connect4.healow.com. Production access requires per-practice activation through eClinicalWorks' On-Demand Activation process.

What are common eClinicalWorks integration problems for PGx?

The most frequent issues are local lab codes in ORU messages without LOINC translations, PDF-only result delivery with no discrete OBX observations, CDS Hooks endpoints not registered in the eCW configuration, and patient identifier mismatches between the lab's MRN namespace and the practice's. Each has a defined fix in the middleware or interface engine configuration.

How do you trigger a PGx alert at prescribing time in eClinicalWorks?

Deploy a CDS Hooks service registered with the eCW instance to receive order-sign hook calls. The service queries the patient's PGx Observations, evaluates the proposed medication against the gene-drug interaction database, and returns an alert card with the recommendation and evidence grade directly in the prescribing workflow.

Can eClinicalWorks integrate PGx results from external labs?

Yes. Clinical labs transmit PGx results to eClinicalWorks via HL7 v2 ORU messages over MLLP, batch SFTP feeds, or FHIR Observation writes. HL7 v2 ORU is the most reliable transport for ensuring results appear in the eCW Results section with full clinical context.

What are the main limitations of eClinicalWorks FHIR for PGx?

eClinicalWorks' FHIR support focuses on US Core profiles, which do not fully cover the depth of genomic data structures required for complex PGx use cases. Sophisticated PGx signals, including medication intelligence simulation and reanalysis workflows, typically require HL7 v2 ORU mappings or a middleware layer to ensure discrete results persist in the correct lab and results locations.

Recommended

• PGx in the EHR with FHIR & CDS Hooks | SignalPGx
• Insights | SignalPGx
• From Genotype to Guidance: The PGx Pipeline | SignalPGx
• Scaling PGx Reporting Without Headcount | SignalPGx