Child pages
  • openEHR 2014 Roadmap - Product and Market
Skip to end of metadata
Go to start of metadata

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...

ConformanceLevelHow tested
Versioning, audit and Contribution1
Full RM support1

Test for canonical XML, JSON for:

  • test COMPOSITION
  • test....
ADL/AOM 1.4 support1
Templating support1
Archetype-based data validation1

Basic Service Interfaces / APIs

  • Contribution commit
1
virtual EHR API2
Demographic API2
Knowledge API2
AQL2
GDL3
ADL/AOM 2 support3

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, 2, ...tool can read & write non-specialised test archetypes
SpecialisationADL 1.4, 2, ...tool can read & write specialised test archetypes with various features
SlotsADL 1.4, 2, ...tool can read archetypes containing slots
TemplatesADL 1.4, 2, ...tool can read archetypes containing slot fillers, mandation, removal, etc
TerminologyADL 1.4, 2, ...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 - Connectathons

Rules for connectathons

Commercialising the Platform 


  • No labels

1 Comment

  1. I played around with a wee mindmap and this is how it turned out

    • Invivo API
      • Level 0
        • Export data as openEHR compositions
      • Level 1
        • EHR services
          • Create
          • Update
          • Delete
          • Report status
          • Link to external Id
        • Composition
          • Commit compositions
          • Retrieve compositions
          • Update composition
          • Validate composition vs archetypes (unless full template validation available).
          • Audit / versioning
          • Delete composition
          • Support contributions
      • Level 3
        • Validate composition vs template
        • Ocean TDD import - make 'formal standard'
        • Marand Web template import - make 'formal standard'
        • Template management in operational repository i.e upload, update, delete
      • Level 4
        • Query services
          • AQL