Provider patient intake recipe
Build referral intake for any specialty, with an importable Brightree patient match/create example and explicit business-result branches.
Start from an extracted document
For any specialty, intake starts with referral classification, patient identity, coverage, service requirements, and the destination EHR or billing system. Discover the supported actions for that destination before building. The downloadable example implements the patient matching and creation segment using Brightree as one adapter. It is not a complete fax-to-paid-claim pipeline. First upload and extract the referral through your configured intake workflow; supply its organization-owned document_id as trigger_data. Confirm extracted first name, last name, and birth date, configured Brightree credentials, and search/create support for your organization. Use synthetic referrals in a test connection before production.
Discover these actions before importing
Load brightree_check_patient_exists and brightree_create_patient_from_document using authenticated action discovery, and check /integration-connections. Both integration nodes use error_strategy=fail_branch with an explicit error edge to review. The graph also checks success before using exists. It reuses an existing match, creates only when ready_for_patient_create=true, and branches on creation success. Ambiguous matches and missing demographics stop at a review annotation. Those comment nodes identify the outcome; they do not send notifications or create review tasks. Replace them with a configured, discovered review action if your operation requires a queue or alert.
Validate against your organization before importing or publishing.
Explore{
"kind": "genhealth.workflow_definition",
"schema_version": 1,
"workflow": {
"name": "Provider intake: match or create an extracted patient",
"description": "Requires an extracted organization-owned document and configured Brightree strategy. Review endpoints are annotations only.",
"nodes": [
{
"id": "match",
"type": "integration",
"name": "Check extracted patient",
"config": {
"handler": "brightree_check_patient_exists",
"params": {
"document_id": "{{trigger.default.document_id}}",
"force": false
},
"_group": "Brightree"
},
"error_strategy": "fail_branch"
},
{
"id": "matched_ok",
"type": "if",
"name": "Match succeeded?",
"config": {
"condition": "{{match.default.success}}"
}
},
{
"id": "exists",
"type": "if",
"name": "Patient exists?",
"config": {
"condition": "{{match.default.exists}}"
}
},
{
"id": "can_create",
"type": "if",
"name": "Ready to create?",
"config": {
"condition": "{{match.default.ready_for_patient_create}}"
}
},
{
"id": "create_patient",
"type": "integration",
"name": "Create or reuse patient",
"config": {
"handler": "brightree_create_patient_from_document",
"params": {
"document_id": "{{trigger.default.document_id}}"
},
"_group": "Brightree"
},
"error_strategy": "fail_branch"
},
{
"id": "created_ok",
"type": "if",
"name": "Creation succeeded?",
"config": {
"condition": "{{create_patient.default.success}}"
}
},
{
"id": "existing_patient",
"type": "comment",
"name": "Existing patient",
"config": {
"heading": "Matched",
"body": "Use match.default.patient_key for a subsequent reviewed step."
}
},
{
"id": "creation_success",
"type": "comment",
"name": "Patient resolved",
"config": {
"heading": "Resolved",
"body": "Use create_patient.default.patient_key for a subsequent reviewed step."
}
},
{
"id": "review",
"type": "comment",
"name": "Review required",
"config": {
"heading": "Review",
"body": "Stop here; replace this annotation with your configured review task or alert."
}
}
],
"edges": [
{
"source_node_id": "match",
"source_output": "default",
"target_node_id": "matched_ok",
"target_input": "default"
},
{
"source_node_id": "matched_ok",
"source_output": "true",
"target_node_id": "exists",
"target_input": "default"
},
{
"source_node_id": "matched_ok",
"source_output": "false",
"target_node_id": "review",
"target_input": "default"
},
{
"source_node_id": "exists",
"source_output": "true",
"target_node_id": "existing_patient",
"target_input": "default"
},
{
"source_node_id": "exists",
"source_output": "false",
"target_node_id": "can_create",
"target_input": "default"
},
{
"source_node_id": "can_create",
"source_output": "true",
"target_node_id": "create_patient",
"target_input": "default"
},
{
"source_node_id": "can_create",
"source_output": "false",
"target_node_id": "review",
"target_input": "default"
},
{
"source_node_id": "create_patient",
"source_output": "default",
"target_node_id": "created_ok",
"target_input": "default"
},
{
"source_node_id": "created_ok",
"source_output": "true",
"target_node_id": "creation_success",
"target_input": "default"
},
{
"source_node_id": "created_ok",
"source_output": "false",
"target_node_id": "review",
"target_input": "default"
},
{
"source_node_id": "match",
"source_output": "error",
"target_node_id": "review",
"target_input": "default"
},
{
"source_node_id": "create_patient",
"source_output": "error",
"target_node_id": "review",
"target_input": "default"
}
]
}
}Validate, publish, and run
Follow the lifecycle in the agent quickstart, using this envelope for preflight and import. Run with trigger_data={"document_id":"<YOUR_ORGANIZATION_DOCUMENT_UUID>"} and a new opaque idempotency key. The smoke-test Python client deliberately uses only the synthetic smoke-test definition; use the documented REST/MCP lifecycle for this connected-system recipe.
| Case | Expected business route |
|---|---|
| Check succeeds and exists=true | existing_patient; do not create a patient |
| Check succeeds and ready_for_patient_create=true | create_patient, followed by creation_success |
| Check cannot establish a unique match or required demographics | review, or a hard node failure requiring authorized investigation |
| Create succeeds with created=false | creation_success; an existing record was reused |
| Create returns a branchable failure | review; never continue to order creation |
| Connection/transport fails with unknown write outcome | Stop and reconcile before another run |
Extend the intake workflow
Discover OCR, demographics extraction, eligibility, policy evaluation, and order actions separately. Verify their required fields and organization configuration; do not assume an output from one action is a compatible input to another. Add qualification and eligibility gates before order creation, including business failures and any required human review. Record the connected-system identifiers needed to verify the result independently of orchestration status.