MedTechLabel WP2 T1.1 Information Model Guide
0.4.3 - ci-build

MedTechLabel WP2 T1.1 Information Model Guide, published by HL7 Europe. This guide is not an authorized publication; it is the continuous build for version 0.4.3 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/hl7-eu/medtechlabel-wp2-im/ and changes regularly. See the Directory of published versions

Framework

This page is intended to analyse and document the underlying framework so that it can be stored in a database to fully align consistency:

Data Model

The framework focuses on the requirement and the evidence to where it is found. Therefore, a standard/specification links to a set of individual (globally defined) requirements by adding an evidence to where it is found in combination with the statement.

The requirement then is directly pointing to a specific digital label element.

Framework (as a Data Model)Framework (as a Data Model)Organizationorg_id: idname: stringcountry: stringDig. Label Elementdle_id: idtitle: stringdescription: stringcategory: codeinformation_type: codedata_type: codecardinality: codehuman_readability_needed: booleanmachine_readability_needed: booleanintended_user: stringinformation_owner: codeauthorative_source: codelifecycle: codenotes: stringRequirementreq_id: idtitle: stringdescription: stringprovision_type: codeinformation_environment[]: codecategory: codenotes: stringdetailsOfRequirementSourcesrc_id: idtitle: stringdescription: stringreference: stringsource_type: SRC_TYPEsource_status: SRC_STATUSbiblio_verfication_status: VER_STATUStechnical_cmte: stringrelease_date: datejurisdiction: codeauthority_level: codeanalysis_priority: codeaccess_copyright: codenotes: stringEvidencereq_id: idsrc_id: idreference/section: stringoriginalStatement: stringGlossaryterm_id: idtitle: stringdefinition: stringspecifies1..*1combined withby evidence1..*1..*more specialized(=parent of)issuing bodycomes from1..*

The details of how a requirement can reference a digital label elements require further examination whether a generic representation is possible or requires different specialisations!?

Alternative Framework

As a result from initial tests the following framework is proposed:

Alternative Proposed Framework (as a Data Model)Alternative Proposed Framework (as a Data Model)Organizationorg_id: idname: stringcountry: stringDig. Label Elementdle_id: idtitle: stringdescription: stringas ontologyObjectElementData TypeFormattingProcedureCodeSourcesrc_id: idtitle: stringdescription: stringreference: stringsource_type: SRC_TYPEsource_status: SRC_STATUSbiblio_verfication_status: VER_STATUStechnical_cmte: stringrelease_date: datejurisdiction: codeauthority_level: codeanalysis_priority: codeaccess_copyright: codenotes: stringSectionsrc_id: idsectionparagraphstatementwith 3 columns:- section (recommended)- page (optional)- text (mandatory)Evidencesrc_id: idsectionparagraphconformanceVerbrelationshipcardinalitywith 5 columns:- source- conformance verb (or parenthesis / boolean operation)- relationship- cardinality- targetGlossaryterm_id: idtitle: stringdefinition: stringdetails ofstandard1..*documentation 0..*source 0..*1target 0..*1grouping       more specialized(=parent of)issuing bodycomes from1..*

Current Findings

  • (digital) label elements
    • it is a very long and detailed list already
  • source type: "internationl standard" vs. "European standard" can be derived from issuing organisation; should be "standard" only
  • requirements: given that requirements are the binding between the source and a digital label element this list is even longer than the one for the elements
  • evidence: this is the reference to a section/paragraph in the standard where a requirement occurs.
  • identifying requirements and reusing it seems to be reasonable approach in order not to get too many entries.
  • copying relevent paragraphs from the standard in order to quote the requirement seems to be reasonable but it appears that due to the nature of how standards are written is an inappropriate way forward because it will be hard to identify to where a requirements should be bound to.

Requirements for the Framework

  • editable
  • cooperation between different contributors
  • versioning: tracking changes

Process

Following a first draft for a process to collect the requirements and to populate a database as well as feeding the information model:

ProcessProcessContributorRepository: Requirements ContributorRepository: Requirements Repository: Information Model ContributorContributorRepository:DB InputRepository:DB InputRequirementsDatabaseRequirementsDatabaseRepository:Info ModelRepository:Info ModelInformation Model(Website)Information Model(Website)ContributorRepository: Requirements download latest fileedit (contribute)submit changesidentify and updaterequirement identifierload/update to databaseextract data forinformation modelgenerateinformation model(details as codesystems)

Open Topics

The following topics need to addressed:

  • cooperatively populate database
    • several contributors can work on content in parallel
    • tracking is enabled