The IG and how to shape it¶
For years, every organization solved the FHIR to OMOP problem independently, and the solutions lived in institutional memory and internal wikis. That is changing, and the change is happening right now in a process you can participate in.
What the guide is¶
The FHIR to OMOP Implementation Guide is developed under HL7's Vulcan accelerator in collaboration with the OHDSI community. It is the product of the HL7 and OHDSI partnership announced in 2021, whose stated aim was to align the two standards so that data captured in a clearly defined way can move into a single common data model.
The guide's scope is the common core of EHR data, which is exactly the material this site covers: person, encounter, condition, observation, medication, procedure.
What it contains:
- A primer for implementers: general guidance, best practices, and considerations that are customizable to individual implementations
- Concept mapping principles and patterns
- FHIR logical models for OMOP CDM tables, which express the OMOP CDM in FHIR's own modeling language
- FHIR StructureMaps written in FHIR Mapping Language, giving executable transformation definitions
- A connectathon validation package for testing an implementation against a shared reference
- Supporting terminology infrastructure
The logical models and StructureMaps are the technically interesting part. They mean the transformation can be expressed as a specification artifact rather than as prose that each team re-implements, which is what makes convergence possible.
Where it stands¶
Edition 1 was published as an informative specification in April 2026. Informative means it is published guidance rather than a normative standard.
A version has moved to Standard for Trial Use ballot in the September 2026 cycle. This version was tested at the July 2026 connectathon, where multiple participants ran independent pipelines to a conformant result, independent tools converged on the same validation findings, and at least one participant used the open-source reference code to learn the transformation by building their own pipeline from it.
The current build is at https://build.fhir.org/ig/HL7/fhir-omop-ig/en/, and the repository is HL7/fhir-omop-ig on GitHub.
Dates for the current cycle
Ballot pool sign-up closed August 13, 2026. Comment period opens August 14 and closes September 14, 2026.
Enrollment closes before voting opens, which is the deadline that catches people every cycle. You do not need to be an HL7 member to comment; non-members can register as commenters and members can vote.
Check the HL7 balloting page for the current cycle's dates, since these move.
Why the ballot process deserves your time¶
HL7 is an ANSI-accredited standards developer. That accreditation carries a specific and useful obligation: every comment submitted through a ballot receives a formal disposition, and negative votes are reconciled on the record.
That is a documented obligation on the working group, and it is the mechanism by which practitioner experience changes a specification instead of becoming a workaround in one organization's codebase.
If you have built a FHIR to OMOP pipeline, you have made decisions, defended them in a design review, and lived with the consequences. That accumulated judgment is exactly what a ballot exists to capture.
Where the guide most needs practitioner input¶
The working group has been explicit about the friction points, and they will be familiar if you have read the rest of this site. They are the same problems this curriculum spends most of its time on, which is a reasonable sign that both are looking at the real thing.
Whether a given Observation belongs in MEASUREMENT or OBSERVATION, and what the guide should say when the source makes that ambiguous. Covered in the observations chapter.
Constructing VISIT_OCCURRENCE from Encounter when the source encounter model does not resemble a visit. Covered in the visits chapter.
What to do with a source code that has no standard concept, and how much of that decision the guide should specify rather than leave to local convention. Covered in domain routing.
Vocabulary binding: where the guide names a value set, where it should, and where it names one that does not survive contact with real source data.
Temporal precision when FHIR gives you a year and the OMOP CDM column wants a datetime. Covered in the person chapter.
value_as_number, value_as_concept, unit normalization, and the places where information quietly disappears in between. Covered in the observations chapter.
Every one of those is a decision somebody has made and lived with. If you are that somebody, the guide would be better for hearing it.
How to read the guide alongside this site¶
They serve different purposes and work well together.
This site teaches you why the decisions are hard and what is at stake in each one. It is written to build understanding, and it takes positions where the community has converged and presents options where it has not.
The guide specifies what to do, in a form that is machine-processable and formally reviewed. It is written to produce interoperable implementations.
A reasonable sequence: read this site to understand the problem space, read the guide's primer for the specification's framing, then read the StructureMaps for the domains you are implementing. When the guide's choice differs from what you would have done, examine that difference, and if you still disagree after examining it, that is a ballot comment.
How to participate¶
Read the current build. Start with the primer, then the domain you know best.
Find where your use case is wrong. Not where the guide is incomplete in general, but where it makes a claim that your source data would break. That specificity is what makes a comment actionable.
Submit through the process. Jira links for comment submission are under the Support tab in the guide. Comments submitted through the formal channel get formal dispositions. Comments made in a hallway do not.
Join a connectathon. Testing an implementation against a shared reference is how ambiguities get found. The July 2026 event demonstrated exactly this: independent pipelines converging, and independent tools agreeing on validation findings, which is the strongest available evidence that a specification is specifying something real.
Watch the OHDSI forums and the Vulcan project pages. The OHDSI forums carry the community discussion, and the EHR data to OMOP CDM working group is the natural home for this material.
A note for people newer to the field¶
You may feel that a standards ballot is for other people, more senior people, people who have been doing this for fifteen years.
That instinct is understandable and it is wrong in a specific way. The people writing a specification are necessarily working from their own experience, and their experience is not a random sample of the implementations that will have to use it. Someone who has just built a pipeline against an unusual source, or a small site's data, or a rare disease registry, knows something the working group cannot know from the inside.
The comment does not have to be sophisticated. "We have a source where Encounter is emitted per clinical service with no partOf, and the guidance in section X does not tell us what to do" is a genuinely useful comment. It names a real case the specification does not cover.