Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Conformance

Requirement

Provide means for procurement and government to specify requirements.

Proposed approach: IHE

  • publish 'profiles'
  • vendors come to connectathon and demonstrate interop for profile A, B, C etc

Profiles - areas of conformance

What openEHR 'profiles' are required? Initial notes...

ConformanceHow tested
Engineering Conformance
Reference model

Test for canonical XML, JSON for:

  • test COMPOSITION
  • test....
Content conformance
AQL 
GDL 
Interfaces / APIs
  

A possible grid based for conformance based on RM modules

RM
module

Canonical
representations
supported

Archetype
support 
Template
support 
QueriableAPI
support 
Terminology
EHR (COMPOSITION,
SECTION, ENTRY) 

XML

JSON

binary

other

solution supports archetypes for any content based on this part of RMsolution supports templates for any content based on this part of RMsolution supports queries against data based on archetypes and this part of RMsolution has APIs for content based on this part of RM

solution supports querying that uses / includes external terminologies;

which terminologies supported

Demographic      
EHR Extract      
Core (date types,
structures, identifiers)

which data types

 

     

Conformance of content model tooling

Model featureLevelTest criteria
Basic archetypeADL 1.4, 1.5, ...tool can read & write non-specialised test archetypes
SpecialisationADL 1.4, 1.5, ...tool can read & write specialised test archetypes with various features
SlotsADL 1.4, 1.5, ...tool can read archetypes containing slots
TemplatesADL 1.4, 1.5, ...tool can read archetypes containing slot fillers, mandation, removal, etc
TerminologyADL 1.4, 1.5, ...tool can support models containing terminology ref-sets

Conformance for Clinical Decision Support components / solutions

Key areas:

  • tools
  • authoring
  • execution

Conformance by Solution 'stack' level

Sigurd From (DIPS), mentioned technology levels from original specification diagrams in architecture overview.

Silje Ljosland (Bergen) mentioned:

  • flexible / customisable UI
  • mobile device support

Other Conformance areas

Other areas that could be specified and tested:

  • Scalability: volumetrics, transaction processing rates
  • integration - demonstrate systems can talk to each other using:
    • APIs
    • EHR Extract
    • 'openFIRE'

Conformance Testing

Commercialising the Platform 

 

  • No labels