OPT 1.4 Specification

Specifications ADL
21

I guess you still need to do some RM mapping in order to map the metadata/definitions, because metadata instances (e.g. specific OPTs) depend on a specific RM.

On the other hand, you can go up in the semantic hierarchy and want to map the metadata models, which are (in the case of openEHR) independent from the underlying RM.

22

@birger.haarbrandt The use-case is using the MDM-Portal for storing meta data as ODM as an alternative for the Archetypes/Templates, since the ODM meta data in theory can be used for many different things, not only study data.

@pablo Yes, I know. I thought of mapping the StudyEvent to a Composition or maybe an Observation, and putting the Forms into the as a cluster of clusters of ItemGroups. Let me know if you would recommend a different approach.

23

I don’t know the ODM model. But it seems your approach is mapping reference models, not their metadata. That is how I proceed when I need to map HL7v2/CDA/FHIR to openEHR RM. The approach is not generic, but works.

24

I think there is a misunderstanding: By metadata, I mean the “structural metadata” as which datafields are available, how many occurences they may have (like a XSD) and not the “administrative metadata” like who has created an resource at which point in time. In ODM, the structural metadata is stored in a tag called “MetaDataVersion”, this is why I’m talking about metadata all the time.

As far as I understood, openEHR has multiple stages of describing the structural metadata of the final “composition” resource (correct me if I’m wrong):

  • BMM, which is used to describe the RM, a set of basic classes
  • ADL/AOM, which is used to constrain classes of the RM
  • OPT, which puts multiple of those constrained classes together for a specific use-case

What I don’t want is to create a new version of the RM. As far as I can see, most RM classes are just containers for the very generic ITEM_STRUCTURE. The ITEM_STRUCTURE is constrained by AOM from a technical point of view, but in my eyes, it is less of constraining but more of specifiying the actual XSD for the information, which is stored in that Archetype.

Mapping the “administrative metadata” like creation time, copyright etc. to the corresponding fields in the RM would be just a bonus, my focus is on having a field for each Item the ODM allows in the final OPT.

25

it is constraining in the sense that whatever you don’t specify in the archetype is assumed to come as is from the reference model. You actually can’t specify constraints on sharing typing nodes in XML Schema (e.g. two different ELEMENTs), that’s why another artifact, such as ADL, is needed

26

I have looked at this general issue before w.r.t. generic SDTM representation, CDISC BRIDG and so on, and my previous conclusion was that it would probably be worth adding some classes to the openEHR RM to accommodate ‘study data’ structures generally. The reason to do so would be to provide two data pathways that could potentially be useful:

  • a pathway for existing SDTM data e.g. BRIDG, ODM etc to be imported in a relatively straighforward fashion
  • a known transformation pathway for openEHR native EHR data, including collected during a clinical trial, to be converted into an SDTM like form that is trial- and data-set- centric rather than patient centric.

This additional modelling would take advantage of the openEHR versioning, audit, and other context attributes as much as possible.

This doesn’t help you in the immediate short term, but I’d be interested to see an effort materialise in this area in openEHR to provide more direct model and tool support for clinical trial and other ‘study’ data.