epic: computer-use EMR workflow automation (research first)

[peterkc]

Overview

Many EMR systems in home health expose weak or no integration APIs; browser-level automation (DOM-driven plus vision-assisted) is a credible additional sync transport for those targets. This epic tracks a research-first exploration of computer-use automation as an emr-sync transport. The automation driver lives in its own repository (heavy dependencies, distinct security/testing posture — credentialed browser sessions demand their own threat model); HDP integrates only through the transport-agnostic adapter contract established in the consolidation epic.

Scope

In scope: research artifact, adapter contract definition. Out of scope (this repo): the automation driver implementation itself.

Decomposition

• spike: computer-use research hub — security posture, sandbox, failure taxonomy #18 — research hub: security posture, sandbox selection, failure taxonomy (hub lives in vault/research/; driver code in its own repository)
• Define the adapter contract between hh-emr-sync and an automation driver

Success Criteria

• Research hub records security posture, sandbox decision, and a failure taxonomy with hardening recommendations — the transport need is already established by the API-less EMR segment; the open question is how browser-driven workflows fail and how to harden them
• Adapter contract documented; an HTTP-API adapter and an automation adapter are interchangeable behind it

Verification

• hh-emr-sync currently declares only httpx as its transport dependency (pyproject), presuming an API that many target systems lack
• Related: depends on the consolidation epic's transport-agnostic seam (epic: package consolidation — trim to earned complexity #11); the OSS-readiness epic (epic: OSS release readiness #5) is complete — this epic is active