RE: ADL validity rules on CKM

[pablo pazos]

Hi Thomas,
I think it would be very useful to have a centralized list of validity rules 
with a reference to the source (specs, CKM, other specific tool, good practice, 
local rule, etc.).
As a developer, that would help me to use those rules in software.
And as a clinical modeler I can check those rules while designing an archetype 
or a template (manually or using a tool).
The spec rules should be on specs (doh!) but I think we might need something 
more dynamic that we can use to add / maintain rules from all the current 
sources, like a github repo for rules (can be a page on the openEHR wiki o the 
wiki on a github repo).

-- 
Kind regards,
Eng. Pablo Pazos Gutiérrez
http://cabolabs.com

Subject: Re: ADL validity rules on CKM
To: openehr-technical@lists.openehr.org
From: thomas.be...@openehr.org
Date: Wed, 15 Jun 2016 12:03:13 +0100


  

  
  
Hi Pablo,

only a few rules were specified in ADL/AOM 1.4 - you can see them
  in the ADL1.4 spec - I think you will find the newer
HTML version easier to use. They were not collected in an
  easy to read list, but I think we could do this easily enough by
  constructing an index of the relevant paragraph type, and
  inserting that into the document. I'll see what is possible in
  Asciidoctor.



In ADL2, it is the AOM2
spec that provides the validity rule definitions.



I'm not sure what the total set Sebastian uses is, but I suspect
  it includes some of the AOM2 rules, i.e. those that would have the
  same meaning for ADL1.4 archetypes.

We should improve how these rules are represented in the specs
  potentially, and a minor update to the ADL1.4 spec could be used
  to update the effective rule set for ADL 1.4

- thomas





On 14/06/2016 07:54, pablo pazos wrote:



  
  Thanks for the input Sebastian,




  Are all of those internal to the CKM?
  Is there any plan to document them in some place to have
all the rules together?
  

  
  Maybe there are a lot of internal rules that we don't
know of and would be useful to have them documented. (Maybe
a task for the clinical models program?)
  

  

  



  


___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org   
  ___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: ADL Workbench exceptions when opening the audiogram archetype

[Thomas Beale]

Pablo,

I suggest you try the newer Windows (64-bit)   2.0.6.2902 build 
. To access CKM 
archetypes, all you need to do is to follow the instructions here 
for 
the CKM-mirror repository, and the ADL WB will check the whole repo out 
via Git (which you need to have findable on the machine).


If you have any further problems, please report them on the adl-tools 
Git project issue tracker .


thanks

- thomas



___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: ADL validity rules on CKM

[Thomas Beale]

Hi Pablo,

only a few rules were specified in ADL/AOM 1.4 - you can see them in the 
ADL1.4 spec - I think you will find the newer HTML version 
 
easier to use. They were not collected in an easy to read list, but I 
think we could do this easily enough by constructing an index of the 
relevant paragraph type, and inserting that into the document. I'll see 
what is possible in Asciidoctor.


In ADL2, it is the AOM2 spec 
that provides the 
validity rule definitions.


I'm not sure what the total set Sebastian uses is, but I suspect it 
includes some of the AOM2 rules, i.e. those that would have the same 
meaning for ADL1.4 archetypes.


We should improve how these rules are represented in the specs 
potentially, and a minor update to the ADL1.4 spec could be used to 
update the effective rule set for ADL 1.4


- thomas


On 14/06/2016 07:54, pablo pazos wrote:

Thanks for the input Sebastian,

Are all of those internal to the CKM?
Is there any plan to document them in some place to have all the rules 
together?


Maybe there are a lot of internal rules that we don't know of and 
would be useful to have them documented. (Maybe a task for the 
clinical models program?)




___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

SV: Personal Health Record using CHBase (related to Health Vault)

[Bjørn Næss]

I have not looked into this before. This is a platform we have to deal with 
somehow – especially vendors in the Swedish market that wants to integrate with 
patient data.

Have you done any investigation on the datatypes to compare with openEHR 
clinical models?
In what way are the clinical models developed in CHBase?
Who is the owner of this platform and specification?

Vennlig hilsen
Bjørn Næss
Produktansvarlig
DIPS ASA

Mobil +47 93 43 29 10

Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] På 
vegne av Erik Sundvall
Sendt: mandag 30. mai 2016 17.50
Til: openehr-technical@lists.openehr.org
Emne: Personal Health Record using CHBase (related to Health Vault)

Hi!

The Swedish Government is financing and handing out a Personal Health Record 
service/platform to the Swedes. Now developers can find info about it at 
http://developer.halsaformig.se/

It seems to be based on CHBase http://www.getrealhealth.com/chbase/ that uses 
many of the API features equal or similar to Microsoft Health Vault.

The health-related PHR models are fairly simple (not many datapoints/details) 
and there are not very many models. The main ones are listed at 
http://developer.halsaformig.se/Reference/DataTypeMapping  and if you register 
for a free developer-account at https://developer.chbase.com/ you can read more 
details, for example this:

  *   Extending data types at 
https://developer.chbase.com/chbase/en-US/docs/Develop/Dn783274 that tells many 
things* including that any datatype can be extended by arbitrary XML as long as 
there is a transform backt to HTML registered with URI.
  *   HL7 FHIR integrations are being worked on.
Now to the questions:

  *   Have any of you already looked into openEHR mappings to/from CHBase or 
Microsoft Health Vault?
  *   The extension mechanism in CHBase is very permissive, using free-form 
XML, that could of course lead to semantc chaos with several overlapping 
incompatible extensions for the same kind of clinical data. I guess it could 
aslo be used to carry some suitable forms of openEHR-data in a more diciplined 
reusable manner. Any thoughts about that?
  *   Would it be a good idea to define a canonical way of storing openEHR data 
in CHBase/HealthVault so that all openEHR-based systems interacting with those 
products do it the same way and thus can exchange the semantically richer 
openEHR-based data as extensions via the PHRs? (Useful in the cases where that 
is the one of the few viable ways due to legal restrictions etc. Of course that 
is an unnecessary detour in the cases when you are allowed to do direct native 
communication between openEHR systems.)

(I guess this would be a suitable task for master-thesis students or beginning 
PhDs

Best regards

Erik Sundvall　

Ph.D. Medical Informatics. Information Architect. Tel: +46-72-524 54 55 (or 
010-1036252 in Sweden)
RÖ:　
erik.sundv...@regionostergotland.se 
(previously lio.se) http://www.regionostergotland.se/cmit/
LiU:　erik.sundv...@liu.se　
http://www.imt.liu.se/~erisu/







*) Excerpt from https://developer.chbase.com/chbase/en-US/docs/Develop/Dn783274 
below:



When building your application, you may find that you need to store additional 
information with an existing data type. For example, if you are using the 
Height data type, but you want to keep track of whether people were sleeping 
immediately before height was measured because the spine compresses during the 
day. The question is whether to:

  *   Incorporate this information into the existing base data type
  *   Use some other existing data type
  *   Ask the CHBase developers to create a new data type
  *   Extend the existing data type

To determine the appropriate course of action, inquire in the CHBase 
Forum.

If the response to your inquiry is that the additional information should be 
stored as an extension of an existing type, you use the 
Extensions
 property of the 
CommonItemData
 object returned by the HealthRecordItem . . :: . . 
CommonData
 property, which is a collection of 
HealthRecordItemExtension
 objects. By default, there's nothing in this list. If you have an instance and 
you add an extension instance to it, the framework saves that instance to the 
server and returns it when you read that instance back out.

CHBase data types can be extended by inserting XML into the 
HealthRecordItemExtension or by using a custom extension class. In the first 
method, you work with the XML details, which can be a bit clumsy. In the second 
method, you encapsulate the