Is DV_STATE and it's profile constraint C_DV_STATE used anywhere in the specs?

[thomas.beale]

@NeoEHR

I validate each BMM file on its own and as part of the set of all BMM files included in the schema.

Ah - ok! BMM wasn’t designed for that, but it’s easy to fake by manual inclusion of course.

NB: there is a line model_name = <"xxx"> that you will see in schemas intended to be top-level models.

rm_publisher = <"openehr">
schema_name = <"am">
rm_release = <"2.2.0">
model_name = <"AOM2">

If a BMM files doesn’t have that, it probably won’t function on its own.

If you want to implement the inclusion logic (not saying you should!), it’s here…

[NeoEHR (Borut Jures)]

@thomas.beale

If you want to implement the inclusion logic (not saying you should!), it’s here…

I didn’t know about the " model_name" rule. I should include that in the validator.

Thank you for sharing your code. I have something similar to build a list of available models:

@NeoEHR

I’ve implemented automated loading of the included schemas and can now use much simpler list of included specifications:

Conflicting specifications in Archie's BuiltinReferenceModels class

I believe I figured it out. RM releases 1.0.3, 1.0.4 and 1.1.0 work well together. They only clash with the original RM release 1.0.2. I’ve implemented automated loading of the included schemas and can now use much simpler list of included specifications: static const _specifications = [ // 'original/Release-1.0.2/openehr_ehr_102.bmm', //'RM/Release-1.0.3/openehr_rm_103.bmm', //'RM/Release-1.0.4/openehr_rm_104.bmm', 'RM/Release-1.1.0/openehr_rm_110.bmm', 'PROC/Release-1.…

[pablo (Pablo Pazos)]

Hi @thomas.beale , I have created an issue in about this: [SPECPR-379] AOM/AP 1.4 + data_types review about DV_STATE and C_DV_STATE - openEHR JIRA