Epic EHR Analyst: Build Experience, Certification, and What the Role Actually Demands

Job postings for Epic analyst roles routinely ask for “build experience” and “Epic certification” without explaining what either term means in practice, how they relate to each other, or what the path to earning them looks like from inside a healthcare IT program. This article breaks down the Epic analyst role from the ground up – what build experience actually involves across major modules, how Epic certification works and who controls access to it, and how to position yourself for it whether you’re already in healthcare IT or coming from adjacent IT disciplines.

What Is an Epic EHR Analyst

Epic Systems Corporation is the dominant electronic health record (EHR) vendor in the United States. As of the mid-2020s, Epic holds over 30% of the global healthcare IT market share and is used by the majority of large academic medical centers, integrated delivery networks, and community health systems across the country. Kaiser Permanente, Cleveland Clinic, Mayo Clinic, NYU Langone, and hundreds of smaller health systems run on Epic. That market position creates sustained, high demand for professionals who know how to implement, configure, and maintain it.

An Epic analyst sits between the technical infrastructure team and the clinical or operational end users. They don’t write source code – Epic is a closed system with limited API extensibility through standard channels. Instead, they configure the application layer: building workflows, setting up order sets, mapping data fields, configuring user roles and access, creating reporting logic, and connecting Epic to external systems via standard messaging protocols. The scope of work mirrors what a Business Analyst does in requirements and process analysis, combined with hands-on system configuration that configuration teams handle in non-healthcare implementations.

The Epic analyst role is module-specific. You are not an “Epic analyst” generically. You are an Epic Ambulatory analyst, or an Epic Orders analyst, or an Epic Bridges analyst. Each module has its own certification track, its own build patterns, and its own clinical domain. A Willow (pharmacy) analyst understands medication administration workflows. A Beaker (lab) analyst understands laboratory information systems. A Bridges analyst understands HL7 message specifications and interface engine architecture. These are not interchangeable skill sets.

The Epic Module Ecosystem: Where Build Analysts Work

Understanding the module structure is the first step to understanding where your expertise fits. Epic’s product suite spans clinical, operational, and financial domains. Each module is named – sometimes with an internal Epic name, sometimes by functional area.

Most Epic analysts are certified in one primary module and may hold proficiency in one or two adjacent modules. Certification in multiple major modules is rare and commands significant salary premium. The most frequently posted roles in current hiring markets are Ambulatory, Inpatient/ClinDoc, Bridges (integration), Willow (pharmacy), Orders, and Cadence (scheduling).

What Epic Build Experience Actually Means

When a job description says “Epic build experience required,” it means direct, hands-on configuration work inside the Epic system. Not reading documentation about Epic. Not attending training. Not being adjacent to an Epic project as a PM or project coordinator. Build experience means you personally accessed the Epic environment and configured items that were then tested and implemented.

The term “build” is specific to Epic culture. Other EHR platforms use “configuration” or “setup.” In Epic, build refers to the process of creating or modifying system objects inside Hyperspace, the main Epic application interface that analysts use. These objects include order sets, visit types, flowsheets, SmartPhrases, security templates, user records, and the hundreds of other configurable elements that define how the system behaves for clinical and administrative users.

What Build Involves Day to Day

An Epic analyst’s build work starts with a requirement. It might come from a clinical department requesting a new documentation template, from revenue cycle identifying a billing gap, or from compliance flagging a HIPAA-related access control issue. The analyst translates that requirement into Epic configuration – identifying the correct build type, gathering the necessary inputs, building the item in the appropriate Epic environment (usually DEV first), and documenting what was built and why.

For an Ambulatory analyst, a typical build task might be: creating a new visit type for a specialty clinic, setting the scheduling rules (slot length, resource requirements, allowed providers), linking it to the correct charge capture workflow, and configuring the Epic documentation template the provider uses during that visit type. That single visit type touches scheduling (Cadence), clinical documentation, charge capture, and often report logic – which means the analyst needs enough cross-module awareness to ask the right questions before they build.

For a Bridges analyst, build work is different in character. They design and configure HL7 interfaces between Epic and external systems – lab vendors, imaging systems, pharmacy systems, health information exchanges, and payer-facing systems. Build includes mapping HL7 message segments to Epic data fields, configuring the routing rules that determine which messages go where, setting up acknowledgment logic, and testing the interface by sending sample messages through the pipeline and validating that Epic receives and processes them correctly. HL7 v2 message types like ADT (admission/discharge/transfer), ORM (orders), and ORU (results) are the daily vocabulary of a Bridges analyst.

For an Orders analyst, build includes creating and maintaining order sets – structured collections of orders that physicians use to initiate care for a defined clinical scenario. Order sets must be clinically validated, maintained across Epic upgrades, and updated when clinical protocols change. A single order set for sepsis management might include labs, imaging orders, IV fluid protocols, antibiotic administration routes, and nursing instructions. Every element has to be built, tested, and approved by the clinical team before it goes live.

Build Experience vs. Support Experience

Support experience is valuable and necessary – post-go-live systems need skilled people to maintain and troubleshoot them. But support experience without build experience doesn’t qualify you for implementation or go-live roles. If you want access to the most competitive contract and full-time opportunities, build experience is the threshold credential, with certification on top of it.

Epic Certification: How It Works and Who Controls It

Epic certification is not publicly available. You cannot purchase an Epic certification course online, sign up for a training program independently, or pass a self-study exam to get certified. Epic controls the certification pipeline entirely. To become certified, you must be sponsored by an organization that is an existing Epic customer or an Epic-authorized consulting partner.

This is the most important structural fact about Epic certification and the one that confuses IT professionals coming from other certification ecosystems. In the PMP, CISSP, or Salesforce certification world, you register, pay, and take a test. Epic doesn’t work that way. Your employer pays Epic (typically $500-$10,000 per certification, averaging around $5,000) to send you to Epic training – either in person at Epic’s campus in Verona, Wisconsin, or through authorized virtual training. Your employer also controls what module you’re trained on, when you go, and whether they sponsor you at all.

What the Epic Certification Process Involves

Epic certification training typically runs one to two weeks depending on the module. Training covers the module’s build tools, configuration options, clinical workflow context, and the Epic-specific terminology you need to work with. After training, you take a certification exam. Most exams require a score in the range of 80-90% to pass.

Many certification tracks also require a build project. You’re given a project scenario and must submit build work that demonstrates you can configure the relevant module correctly. This project component is where many candidates struggle – particularly if they’ve received training but haven’t had hands-on system time before the exam. Epic builds the project requirement into the certification precisely because knowing how to navigate the system conceptually is not the same as knowing how to build in it accurately.

Epic certifications are version-specific. When Epic releases a major software upgrade (typically annually), certified analysts need to complete update training and sometimes pass a recertification exam to maintain current certification status. Certifications that are one or two versions behind can limit your contract placement options, because health systems running current Epic versions need analysts who know the updated build environment.

Epic Proficiency: The Alternative Track

Epic offers a second track called proficiency. Proficiency allows analysts to self-study from Epic’s materials (accessed through the UserWeb portal, which is restricted to Epic customer organizations) and take the certification exam without attending the full formal training program. Proficiency certification typically requires a slightly lower passing score than full certification – approximately 70-80% versus 80-90% for full certification – but still requires the build project submission where applicable.

Proficiency costs the organization less in training fees and travel, but it demands more from the analyst. Self-studying for an Epic proficiency exam without prior system access is genuinely difficult. The analysts who succeed with proficiency typically have either significant adjacent experience in the clinical or operational domain the module serves, or they’ve had informal system access through a Credentialed Trainer role or a similar position that gave them consistent time inside Epic.

One important distinction: full certification and proficiency are both recognized by health systems as valid credentials. The credential type matters less than the quality of the build experience behind it. A proficiency-certified analyst with three years of hands-on implementation work is more valuable than a newly certified analyst who passed the exam but has never navigated a real go-live.

Breaking Into Epic: Pathways to Your First Build Role

Because Epic certification requires employer sponsorship, getting into the Epic ecosystem without existing access is the central challenge for IT professionals trying to enter healthcare IT. The paths that actually work in practice are more specific than most career advice suggests.

Path 1: Internal Sponsorship at an Implementing Organization

The most direct path is working at a health system that is implementing Epic or expanding an existing implementation. Organizations in active Epic programs need analysts urgently and often sponsor internal candidates – clinical staff, IT generalists, or healthcare operations professionals – rather than compete exclusively in the expensive external market for already-certified talent.

If you currently work in healthcare IT in any capacity – help desk, data analyst, project coordinator, training – and your organization is on Epic, pursuing an internal transfer to the Epic applications team is the most efficient path. You don’t need to be certified to apply for analyst positions that include “certification required within one year of hire.” Many health systems hire on potential and sponsor training after placement.

What you need to demonstrate to get that internal opportunity: familiarity with the clinical or operational domain the module serves, basic analytical skills, and a clear rationale for why you want to make the transition. A nurse who wants to move into Epic ClinDoc (Inpatient) build brings clinical domain knowledge that a generalist IT hire doesn’t have. A billing specialist who transitions to Epic Resolute brings revenue cycle expertise that makes them more effective at gathering requirements and catching configuration errors. Your domain background is an asset in this environment, not a substitute for technical skills.

Path 2: Epic Credentialed Trainer

Epic Credentialed Trainer (CT) is a distinct credential separate from analyst certification. CTs are responsible for training end users on Epic workflows before and after go-live. The CT program gives trainers access to Epic’s training environments, curriculum materials, and – most importantly – consistent time inside the system.

For someone pursuing analyst certification, the CT role is a strategic stepping stone. As a Credentialed Trainer, you learn the clinical workflows deeply enough to teach them, you navigate the system regularly, and you develop relationships with the build analysts who configure what you train. That familiarity substantially reduces the difficulty of the proficiency self-study path. CTs who pursue proficiency certification after a year or two in the trainer role have a meaningful success advantage over cold candidates.

The CT path works best if you’re already inside a health system and looking to transition from training to build. It’s not ideal as a standalone career destination – CT roles pay less than analyst roles and have a narrower growth trajectory. Use it as a platform, not a destination.

Path 3: Healthcare IT Consulting Firms

Several healthcare IT consulting firms that are Epic-authorized partners sponsor certification for consultants they hire. This model requires you to already have enough adjacent IT skills to be placeable on a client project within a reasonable timeframe after certification. Firms look for candidates with strong IT project experience, clinical or healthcare operations background, or both.

The consulting model is high-reward and high-demand. Certified Epic consultants typically work on contract, traveling to client sites during go-live phases and working remotely during build and testing. Contract rates for certified Epic build analysts range from $75/hr to $120/hr or more depending on module specialization and seniority. Senior consultants with five or more full Epic implementation cycles can exceed that significantly on specialized engagements.

The downside of consulting is the travel and the project-to-project variability. Go-live support is intense – weeks of extended hours onsite in the hospital, handling user issues in a live clinical environment where configuration errors have direct patient care implications. Not every IT professional is well-suited to that context, regardless of technical skill.

Path 4: Equivalent EHR Experience as a Bridge

Job postings that say “Epic certification or equivalent EHR experience” acknowledge the certification access barrier. They’re open to candidates with documented configuration experience in other major EHR platforms – Cerner (now Oracle Health), Meditech, Allscripts, or athenahealth. If you have hands-on configuration build experience in one of these platforms and understand clinical workflows, some organizations will sponsor your Epic certification on the assumption that your analytical framework transfers.

The key is framing your experience correctly. “I managed EHR tickets” is not equivalent. “I designed and configured visit types, template workflows, and charge capture rules in Cerner Millennium for an ambulatory specialty clinic deployment” is closer to what they’re looking for. The specificity of your configuration vocabulary signals whether your experience will transfer.

The Epic Analyst’s Role in the Implementation Lifecycle

An Epic implementation follows a structured project lifecycle. Understanding where build analysts fit in each phase clarifies what you’ll actually be doing at different points in a project and what skills matter when.

Discovery and Design Phase

Before any configuration happens, the analyst must understand what to build. This phase involves current-state workflow analysis – sitting with department heads, physicians, nurses, and operational staff to document how they currently work and what they need the EHR to do. The analyst maps these requirements to Epic’s native functionality, identifies gaps where Epic doesn’t do what the department needs out of the box, and presents options: configure within existing Epic capabilities, request a custom extension, or modify the workflow.

This is where the Business Analysis skill set overlaps most directly with the Epic analyst role. BABOK v3’s requirements elicitation techniques – interviews, observation, workshops, process modeling – apply directly to Epic workflow design sessions. An analyst who can facilitate a productive workflow session with a reluctant clinical department and extract a buildable specification from a two-hour meeting is significantly more valuable than one who is technically proficient but struggles to gather requirements from non-technical stakeholders.

Design documentation in an Epic implementation typically takes the form of workflow diagrams and build review documents (BRDs or build specs). These documents capture the current and future state, the Epic configuration decisions that address each requirement, and the testing approach that will validate the build. They’re also compliance artifacts – in HIPAA-regulated environments, changes to access controls and data handling workflows must be documented and traceable.

Build Phase

The build phase is where the analyst spends the majority of their project time on a large implementation. Build work is iterative – initial configuration, peer review, revision, and final review cycles run continuously. On most Epic programs, build happens in a dedicated DEV environment and is migrated through QA and then UAT environments as it passes review gates.

Quality in the build phase comes from precision and documentation discipline. An Epic analyst who builds something correctly but can’t explain what they built or why they made specific configuration choices creates a knowledge debt that will surface at the worst possible time – during a go-live issue at 2 AM when the analyst isn’t available and someone else has to troubleshoot it. Epic’s own best practice guidance emphasizes that every build decision should be documented in the system’s internal notes or in external project documentation.

Build work on an active Epic implementation runs in parallel across modules. The Ambulatory analyst builds visit types while the Willow analyst builds pharmacy workflows while the Bridges analyst builds lab interfaces. These builds intersect – the lab order the Ambulatory analyst puts in an order set must be connected to the lab test the Beaker analyst built, and the result must route back through the Bridges interface the integration analyst configured. Cross-module dependencies are the primary source of integration testing failures, which is why Epic implementations have formal integrated testing phases.

Testing Phase: Integrated Validation Testing

Epic implementations use a structured testing process called Integrated Validation Testing (IVT) or Integrated Systems Testing (IST). This is end-to-end testing across all modules in a shared QA environment, using clinical scenarios that mirror real patient workflows. The analyst who built a configuration is responsible for validating that it works correctly in IVT and for fixing defects found by the QA team or clinical testers.

The testing process mirrors the Software Testing Life Cycle in its structure: test planning, test case execution, defect logging, defect fix, and retest. In Epic terminology, defects found during IVT are called “issues” and are tracked in Epic’s project management system (UserWeb), often mirrored in Jira or ServiceNow depending on the organization’s ITSM tooling.

Epic implementations also conduct a Dress Rehearsal – a simulation of the go-live cutover process using production-equivalent data in the UAT environment. Analysts participate in dress rehearsal by executing their module-specific cutover tasks, validating that migration packages completed correctly, and confirming that the production environment is configured correctly before go-live day.

Go-Live: What Build Analysts Do Onsite

Go-live support is the most demanding phase of an Epic implementation. During go-live week, analysts are onsite in the hospital, available to handle issues from clinical staff in real time. An issue that blocks a nurse from documenting a medication administration or prevents a physician from placing an order cannot wait for a ticket queue. It gets escalated immediately to the responsible analyst for investigation and resolution.

Go-live support requires the analyst to diagnose issues quickly under pressure. The most common go-live issues are: workflow training gaps (user doesn’t know how to use the system, not a build defect), configuration errors that weren’t caught in testing, environment differences between QA/UAT and production that affect behavior, and interface failures that cause data not to flow between Epic and connected systems.

Distinguishing a training gap from a build defect from an interface failure during a go-live is a skill that separates experienced analysts from those on their first go-live. The diagnostic process starts with: can I reproduce this in the production environment? Is this affecting one user or many? Is there a corresponding error in the interface queue? Does this match a known issue logged before go-live? Working through those questions under time pressure, with clinical staff waiting for resolution, is a different kind of competency than build accuracy.

Epic Build Analyst in Practice: A Healthcare IT Scenario

A regional academic medical center with eight hospital campuses and 200+ outpatient clinics is completing Phase 2 of its Epic implementation, bringing four additional ambulatory specialty departments live. The Phase 2 go-live is in 14 weeks. The project team includes Epic Ambulatory analysts, a Bridges integration analyst, a Resolute billing analyst, and a Cadence scheduling analyst.

Week 1: The Ambulatory analyst attends workflow design sessions with the cardiology department. The cardiologist lead wants a specific follow-up note template that pulls in the patient’s last echocardiogram results, cardiac catheterization findings, and current medication list automatically – using Epic’s SmartLinks functionality. The analyst documents this requirement, validates that the specific SmartLinks are available for the data types requested, identifies that the echo results come from an external imaging system via a Bridges interface, and flags the interface analyst to confirm the echo data will be accessible within the expected timing.

Week 3-8: Active build. The Ambulatory analyst configures 14 visit types for the cardiology service line, builds the note templates and SmartPhrases, creates three cardiac-specific order sets including a post-cath protocol, and sets up the provider scheduling templates in coordination with the Cadence analyst. The Bridges analyst builds the interface between Epic and the imaging system’s PACS, mapping the HL7 ORU message from the imaging vendor to the correct Epic result field for echocardiogram reports. The Resolute analyst configures the cardiology billing logic, including the charge capture rules for cardiac catheterization procedures tied to specific CPT codes.

Week 9: IVT. QA runs a clinical scenario: a patient is scheduled for a cardiology follow-up after cardiac catheterization. The scheduler creates the appointment using the correct visit type in Cadence. The physician opens the patient chart during the encounter and opens the follow-up note template. The SmartLink for echo results pulls data – but the wrong result displays. It’s showing a result from a different patient because the HL7 ORU message from the imaging vendor is using an MRN format that doesn’t match Epic’s expected MRN length, causing a mismatch in patient matching logic. The Bridges analyst investigates the message, identifies the field length issue in the OBX segment, corrects the interface mapping, and retests. The defect is resolved in two days. The QA team runs the scenario again and closes the issue.

Week 14: Go-live. The cardiology department goes live Monday morning. By 10 AM, the Epic analyst receives a call: two cardiologists can’t place a post-cath medication order. Investigation reveals that the medication in question – a specific IV anticoagulant – wasn’t built in Willow with the correct route and dosing options for the cardiac cath lab workflow. The Willow analyst is paged, builds the missing medication orderable item in production (after emergency change control approval), and the issue is resolved by noon. The post-go-live issue is logged in the defect tracker with full documentation of the root cause: the medication was identified in the order set by the Ambulatory analyst but the corresponding Willow build wasn’t completed before cutover because the dependency wasn’t documented in the cross-module build tracker.

This scenario illustrates every dimension of what an Epic build analyst actually does – requirements gathering, configuration, cross-module dependency management, integration troubleshooting, and live-environment issue resolution. It also shows where things go wrong in practice: undocumented cross-module dependencies, integration field mismatches, and the gap between what’s built and what end users actually need when they’re in front of a real patient.

HIPAA and Compliance Context for Epic Analysts

Epic analysts work in a HIPAA-regulated environment. Every configuration decision that affects access to protected health information (PHI) – user security templates, role-based access controls, audit logging, data sharing rules – has compliance implications. This isn’t background awareness; it’s an active constraint that shapes configuration decisions.

HIPAA’s Security Rule requires covered entities to implement technical safeguards that control access to electronic PHI (ePHI). In Epic, the primary mechanism for this is the security template – a configuration object that defines what each user role can see and do within the system. The Epic Security analyst (often using the Provider Administration or SER build record) manages these templates. But every module analyst contributes to compliance: the Ambulatory analyst who builds a note template needs to ensure that it doesn’t inadvertently expose sensitive data to roles that don’t have authorization for it. The Bridges analyst who builds an interface needs to ensure that ePHI transmitted via HL7 or HL7 FHIR messages is encrypted and logged in compliance with HIPAA transmission standards.

The CMS Interoperability and Patient Access Final Rule, finalized in 2020, mandates that healthcare organizations provide patient access to their health data through standardized APIs – specifically HL7 FHIR. Epic’s SMART on FHIR implementation enables this. Analysts working on Epic’s MyChart or Interconnect modules need to understand FHIR API architecture and how Epic exposes patient data through its FHIR endpoints. This intersection of regulatory compliance and technical implementation is where healthcare IT differs most sharply from general IT environments.

Skills That Separate High-Value Epic Analysts from Average Ones

Market demand for Epic analysts is high, but the quality gap between analysts is significant. These are the skills that distinguish top-performing analysts from those who are technically adequate but struggle in complex programs.

Epic vs. Other EHR Platforms: How the Analyst Role Differs

IT professionals with experience in other EHR platforms sometimes ask how the Epic analyst role differs from what they’re used to. The fundamental work is similar – requirements, configuration, testing, go-live – but Epic’s market position and closed ecosystem create differences in both career dynamics and technical depth.

The core analytical and clinical workflow skills transfer between EHR platforms better than the technical build skills do. An analyst who has led workflow design sessions, gathered requirements from clinical departments, and managed cross-module integration testing in Cerner can apply those competencies in an Epic environment. They’ll need to learn Epic-specific build tooling, but the contextual intelligence transfers.

Building an Epic Analyst Career: Long-Term Positioning

Career progression for Epic analysts follows recognizable patterns. Entry-level analysts work on specific module tasks under senior analyst supervision during their first implementation. Mid-level analysts lead build for their module independently and mentor junior team members. Senior analysts lead cross-module workstreams, own go-live readiness for their functional domain, and often move into project leadership or Epic consulting principal roles.

The ceiling rises with module depth and implementation breadth. An analyst who has supported one implementation in one module is limited in the senior roles they can access. An analyst who has completed five full implementation cycles across two or three modules, including at least one major academic medical center or integrated delivery network go-live, commands the top of the market. The full cycle matters: analysts who join projects after build is complete and leave before go-live stabilization have gaps in their experience that show up in capability assessments.

Dual certification in complementary modules opens specific career paths. Ambulatory + Cadence is a common combination for patient access-focused roles. Bridges + Beaker works for integration-heavy integration roles at lab-intensive systems. Orders + ClinDoc suits inpatient workflow specialists. Each combination has its own market niche and narrows competition for the roles that require both.

The Cogito/Clarity reporting track is an increasingly valuable adjacent specialty. Health systems generate enormous volumes of Epic data and struggle to extract actionable analytics from it. An analyst who combines module certification with SQL fluency in Epic’s Clarity database and experience with Caboodle data warehouse can move into analytics engineering, population health analytics, or operational reporting roles that pay as well as senior build analyst positions and have different demand cycles – more stable than go-live-driven demand.

One dimension that doesn’t show up in job postings but matters considerably in career trajectory: the ability to work effectively with clinical leadership under pressure. Physicians and nursing directors are not IT stakeholders. They have patient care priorities that will always outrank your project milestone. The Epic analysts who earn long-term consulting relationships and senior internal roles are invariably the ones who can communicate clearly with clinical audiences, adapt to the culture of clinical departments, and maintain composure when a go-live morning involves a department director demanding immediate resolution of an issue that was documented as deferred in the decision log three months earlier.

Epic Analyst Build Experience: What Hiring Managers Actually Look For

When a hiring manager at a health system or consulting firm evaluates an Epic analyst candidate, they’re looking for specific signals in the interview and resume that go beyond “Epic certified” and “build experience.”

The first signal is implementation specificity. Can you name the modules you built in, the organizations you implemented for, the approximate project scale (number of end users, number of sites, number of beds for inpatient go-lives), and whether you stayed through go-live? “I worked on an Epic project for 18 months” is less credible than “I served as the lead Ambulatory analyst on a 12-site go-live for a regional health system, supporting six specialty departments with 280 providers, and I was onsite for all three go-live waves.”

The second signal is defect and issue experience. A candidate who can describe a complex build defect they diagnosed and resolved during testing or go-live – including what the symptom was, how they narrowed down the root cause, what the fix was, and what preventive measure they implemented – demonstrates the kind of analytical depth that separates functional analysts from exceptional ones.

The third signal is cross-functional awareness. Can you explain how your module’s build affected or depended on adjacent modules? An Ambulatory analyst who can explain the dependency between their visit type build and the Cadence provider templates, and who can describe an instance where that dependency caused an integration issue, demonstrates that they understand the system as a whole – not just their slice of it.

The fourth signal is HIPAA fluency. Not as a checkbox, but as a genuine constraint they’ve navigated. Candidates who can describe a specific configuration decision they made differently because of HIPAA access requirements – a role security template, a data sharing agreement that affected an interface build, a patient-facing data element that required compliance officer review before it could be exposed in MyChart – demonstrate that they’ve worked in regulated environments and understand the stakes.

Suggested External References:
1. CMS EHR Incentive Programs and Meaningful Use – Centers for Medicare & Medicaid Services (cms.gov)
2. HL7 FHIR Official Specification – Fast Healthcare Interoperability Resources (hl7.org)