Representing a business identifier for a procedure (EHDS header.identifier) in openEHR-EHR-ACTION.procedure

Specifications
1

Hi all,

EHDSProcedure has a business identifier in its header: EHDSProcedure.header.identifier (0..*, “Business identifier for the object, unique within its system. Supporting disambiguation between different contexts (systems/countries).”). In HL7 Europe Base and Core this maps to FHIR Procedure.identifier. I’d like to trace this requirement back to openEHR, but can’t find an obvious place for it in the archetype.

The use case: telling apart two registrations of the same procedure for the same patient (e.g. the same procedure performed twice on one day), recognising updates of a registration, and deduplicating when the same procedure reaches a system through more than one source.

Options I’ve looked at:

  1. Requestor order identifier (at0054) / Receiver order identifier (at0056) in the protocol. These identify the order, not the procedure itself. One order can result in several ACTIONs (planned, scheduled, performed, completed) and in repeated performances, and not every procedure has an order.
  2. LOCATABLE.uid on the ACTION. Allowed, since an ENTRY is an archetype root, but the Common IM states that uid “will usually be empty in most EHR data” and that nodes are referenced by version id + path. Is version uid + path (or a DV_EHR_URI) the intended way to identify an entry, also towards external parties?
  3. FEEDER_AUDIT.originating_system_item_ids (List<DV_IDENTIFIER>): “Identifiers used for the item in the originating system, e.g. filler and placer ids.” Semantically this looks closest, and DV_IDENTIFIER maps well onto a FHIR Identifier. However, FEEDER_AUDIT seems intended for data converted from non-openEHR systems. Would it also be appropriate for natively created data?
  4. The Extension slot (at0064) with a CLUSTER holding a DV_IDENTIFIER. The slot description explicitly mentions “additional metadata to align with FHIR”. Is there an existing CLUSTER archetype for this?

Our questions:

  • What is the recommended way to represent a business identifier of a procedure in openEHR? Which of the options above (if any) would you use to map EHDSProcedure.header.identifier?
  • Since header.identifier is part of the common header in all EHDS logical models, is there a general pattern (or ongoing work) for mapping the EHDS header to openEHR, for example in relation to Xt-EHR or existing openEHR–FHIR mappings?
  • If none of these fits, would adding an identifier element to the procedure archetype (e.g. in the protocol) be a reasonable change request?

Thanks in advance!

2

Hi Joshua

Very interesting question

The openehr ENTRY.uid attribute is really the equivalent of the FHIR id … a unique internal identifier, whilst the identifier descrbed here is an external cross organisation identifier not allocated internally.

So I would say that at least for now, that feeder_audit is the correct approach.

3

Can you share a bit more about your project please?
Maybe this is of interest to you? An implementation of EPS in openEHR plus FHIR-connect mapping:

We’re looking for contributors to share maintenance of this work.
For those at ehrcon, this afternoon I’m presenting this work.

4

Thanks Ian, that helps. One nuance I’d like to check: I’d describe the EHDS/FHIR business identifier less as not allocated internally and more as allocated by the source system, but stable and meaningful once the data leaves that system. FHIR defines Procedure.identifier as “Business identifiers assigned to this procedure by the performer or other systems which remain constant as the resource is updated and is propagated from server to server”, and EHDS says “unique within its system”. In our setting it will typically be the number the source EHR assigns to the procedure record and exposes for exchange, rather than an identifier issued by a national or cross-organisational authority. If we specified the latter, hardly any source system could populate it. Does that match how you see it?

On feeder_audit I’d be happy to follow your advice. What I’m still unsure about is data created natively in an openEHR system. FEEDER_AUDIT is defined as an “audit trail from non-openEHR system of original commit … or from a conversion gateway which has synthesised this node”, so for a natively created entry there is no originating system to carry the id. Would you still populate feeder_audit in that case, or is the expectation that version uid + path takes over that role when the data is shared?