Holistic view, was :AQL on specific list of compositions

[Bert Verhees]

Contsys will update some definitions. They are now the base of their thinking, 
but I am sure that will change soon. 

Thanks, Gérard, for giving me the opportunity to make my point again. :-) 

We don't call war a peace problem. So why do we call illness a health problem? 

Normally I would not mention such a small thing. But the positive naming could 
be standing in the way of a more holistic view. Healthcare is now about 
care-for illness. Medicine is not always about healing. It are medieval 
understandings in the way we still use them. 

Healthcare must also be for healthy people 

For example, food is important, not only for people with a disease, but also 
for healthy people so that they do not get a disease. 

According businessplans of tech giants, like Google, Amazon, etc,  a PHR will 
contain a holistic view of the consumer (not patient). The PHR will contain 
data from sport, leisure, diseases, yoga, food, everything related to health. 
Not only the negative aspects, but all aspects. This change in philosophy of 
healthcare is taking place quite some time now, but now reaching the upper 
levels of society. 

Preventing diseases will become a major way of spending healthcare money. If 
insurance companies can keep their members healthy, they are saving money. 

If companies do not start to change, they will lose their position on the 
billion dollar market. 
There will be a new business-competition. The patient will become a consumer 
and will give new meaning to the word healthcare. 

Change starts with using words in another way.

Now is the time to start with this. The world is changing fast, and we will 
change with it. 




Verzonden vanaf mijn Xperia™ van Sony-smartphone

 GF schreef 

>HI Ian,
>
>Some definitions from Consys
>These are taken from: https://contsys.org
>
>problem: health condition  
>considered by a healthcare actor 
> to be a problem
>health problemlist:health thread  
>linking a set of health problems 
>health issue: representation of an issue related to the health 
> of a subject of care 
> as identified by one or more 
>healthcare actors 
>episode of care: health related period 
> during which healthcare 
>activities  are performed to 
>address one health issue  as 
>identified by one healthcare  
>professional[
>
>
>
>Gerard   Freriks
>+31 620347088
>  gf...@luna.nl
>
>Kattensingel  20
>2801 CA Gouda
>the Netherlands
>
>> On 20 Aug 2018, at 11:13, Ian McNicoll  wrote:
>> 
>> @Gerard - I have always assumed that Contsys 'Health Issue' equates to 
>> problem.
>> 
>> https://github.com/openehr-clinical/shn-contsys 
>> 
>> 
>> Ian
>> 
>
>
>___
>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: GDPR and OpenEhr.

[Bert Verhees]

There are good arguments in the discussion. I take this message to reply to 
because it is the last for this subject at the moment. 

I am thinking of following situation. This week, Microsoft, Google, Amazon and 
IBM agreed that there must be a health data platform which exposes itself in 
FHIR and API. Apple will certainly connect too. What will run below is not 
specified. It could well be OpenEhr. Their might also be smaller parties which 
will be health data provider. 

The idea is that the patient (or better, consumer) becomes the owner of the 
data. A connected PHR. He gives the healthcare providers access to his data.  
The healthcare data company is a tech company and the consumer choose it like 
he chooses his telephone provider.. Maybe it is a combined service. 

GDPR supports this new market idea. But when the user switches provider, he 
must be sure that all his data are removed from the old provider. 

This is the intention from the tech companies, and it is a good intention.  

Of course the Google's of this earth will be leading, but it is an open market 
so small parties can also enter and compete on price or special features in 
context of mhealth or sport-support or support for special conditions. 

Anyway, I have read about this this week in a journal, and it seems very 
promising. That was my thought about asking. 

I am now writing this from my phone, but tomorrow after 1200 km driving, I can 
come back to this. 

Best regards
Bert

Verzonden vanaf mijn Xperia™ van Sony-smartphone

 Karsten Hilbert schreef 

>On Sat, Sep 01, 2018 at 08:33:08PM +0200, Diego Boscá wrote:
>
>> Supporting hard delete doesn't mean mandate hard delete :)
>
>Indeed. I agree with that.
>
>Karsten
>-- 
>GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
>
>___
>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: GDPR and OpenEhr.

[Karsten Hilbert]

On Sat, Sep 01, 2018 at 08:33:08PM +0200, Diego Boscá wrote:

> Supporting hard delete doesn't mean mandate hard delete :)

Indeed. I agree with that.

Karsten
-- 
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

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

Re: GDPR and OpenEhr.

[Diego Boscá]

And as I said this is covered by the exemptions to hard delete on that law
article, no need for German providers to delete nothing their national law
doesn't allow for.

El sáb., 1 sept. 2018 a las 20:42, Karsten Hilbert ()
escribió:

> On Sat, Sep 01, 2018 at 08:29:33PM +0200, Diego Boscá wrote:
>
> > There is in fact that right, the "right to be forgotten"
> > https://gdpr-info.eu/art-17-gdpr/
> > The requirement you say about Germany is backed by sections 3 (b) and (c)
> > These exceptions do not apply to private providers, so we have the legal
> > need to support that kind of delete operations to allow openEHR systems
> to
> > be GDPR compliant
>
> Whether we like it or not (I do not like it, personally, as a
> patient, but do like it, professionally, as a GP): in Germany
> there is the right to keep a record "as long as there is
> suspicion you might be sued such that you can exercise your
> right to defend yourself". 30 years is the latest you can be
> sued in Germany. So that's when a hard delete can be
> requested (arguably it even becomes mandatory). Period.
>
> However, the provider is legally bound to make sure the
> record is not used after the patient requests that (there's
> other time limits for other things, but that's the most a
> patient can *request* after those other deadlines have
> passed and before 30 years are over).
>
> It doesn't matter what anyone thinks. That is the legal
> situation ATM.
>
> Karsten
> --
> GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: GDPR and OpenEhr.

[Diego Boscá]

Permanent annonimisation is allowed under some prerequisites (see the other
reply, point 3 of art 17). This is a patient right to be exercised with all
consequences. Data will never be lost as the patient has the right of
obtaining a copy of all the information a provider has about him in an
electronic standard when available. Luckily we can provide also that.

El sáb., 1 sept. 2018 a las 20:29, Thomas Beale ()
escribió:

> I continue to wonder what will happen when a cancer patient (perhaps in a
> moment of depression or disaffection with care) asks for the hard delete,
> gets better, then has a recurrence a few years later. What does the health
> system do when *all the notes are really gone*?
>
> I think a better solution is to create a digital locked room when such
> EHRs are put, one-way encrypted with a giant key provided by the patient.
> Then when they have regrets, they can ask - nicely - for their record to
> come out of cold storage.
>
> Another argument against total deletion is that a) the state has invested
> in helping sick patients and b) other citizens have a potential interest in
> health records belonging to those in the same major disease cohort, i.e.
> diabetes, cystic fibrosis, BRCA1 cancer etc. Numerous deletions are
> certainly going to compromise research that looks at longitudinal Dx v
> treatments v outcomes. Perhaps perhaps permanent anonymisation is a better
> solution in this case, with the original patient being given the new EHR id.
>
> I think GDPR has some way to go yet in healthcare...
>
> - thomas
>
> On 01/09/2018 18:57, Diego Boscá wrote:
>
> If a patient uses a private health provider then he has the right of
> taking all that information and move to another provider. In that case he
> will want a hard-delete of data. And I hope private health providers are
> also able to use openEHR ;D
> I think we should also review the "consent" mechanisms we have, as they
> probably should also be tweaked to comply with GDPR.
>
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: GDPR and OpenEhr.

[Karsten Hilbert]

On Sat, Sep 01, 2018 at 08:29:33PM +0200, Diego Boscá wrote:

> There is in fact that right, the "right to be forgotten"
> https://gdpr-info.eu/art-17-gdpr/
> The requirement you say about Germany is backed by sections 3 (b) and (c)
> These exceptions do not apply to private providers, so we have the legal
> need to support that kind of delete operations to allow openEHR systems to
> be GDPR compliant

Whether we like it or not (I do not like it, personally, as a
patient, but do like it, professionally, as a GP): in Germany
there is the right to keep a record "as long as there is
suspicion you might be sued such that you can exercise your
right to defend yourself". 30 years is the latest you can be
sued in Germany. So that's when a hard delete can be
requested (arguably it even becomes mandatory). Period.

However, the provider is legally bound to make sure the
record is not used after the patient requests that (there's
other time limits for other things, but that's the most a
patient can *request* after those other deadlines have
passed and before 30 years are over).

It doesn't matter what anyone thinks. That is the legal
situation ATM.

Karsten
-- 
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

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

Re: GDPR and OpenEhr.

[Diego Boscá]

There is in fact that right, the "right to be forgotten"
https://gdpr-info.eu/art-17-gdpr/
The requirement you say about Germany is backed by sections 3 (b) and (c)
These exceptions do not apply to private providers, so we have the legal
need to support that kind of delete operations to allow openEHR systems to
be GDPR compliant

El sáb., 1 sept. 2018 a las 20:17, Karsten Hilbert ()
escribió:

> On Sat, Sep 01, 2018 at 07:57:31PM +0200, Diego Boscá wrote:
>
> > If a patient uses a private health provider then he has the right of
> taking
> > all that information and move to another provider. In that case he will
> > want a hard-delete of data.
>
> Indeed they will want that, but there is no absolute right
> for a hard-delete (not that I personally like that fact). As
> I said, in Germany, that right currently only takes effect
> after 30 years (that absolute right). In the meantime,
> however, there's a right for sealing against access.
>
> Karsten
> --
> GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
>
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: GDPR and OpenEhr.

[Thomas Beale]

I continue to wonder what will happen when a cancer patient (perhaps in 
a moment of depression or disaffection with care) asks for the hard 
delete, gets better, then has a recurrence a few years later. What does 
the health system do when /all the notes are really gone/?


I think a better solution is to create a digital locked room when such 
EHRs are put, one-way encrypted with a giant key provided by the 
patient. Then when they have regrets, they can ask - nicely - for their 
record to come out of cold storage.


Another argument against total deletion is that a) the state has 
invested in helping sick patients and b) other citizens have a potential 
interest in health records belonging to those in the same major disease 
cohort, i.e. diabetes, cystic fibrosis, BRCA1 cancer etc. Numerous 
deletions are certainly going to compromise research that looks at 
longitudinal Dx v treatments v outcomes. Perhaps perhaps permanent 
anonymisation is a better solution in this case, with the original 
patient being given the new EHR id.


I think GDPR has some way to go yet in healthcare...

- thomas


On 01/09/2018 18:57, Diego Boscá wrote:
If a patient uses a private health provider then he has the right of 
taking all that information and move to another provider. In that case 
he will want a hard-delete of data. And I hope private health 
providers are also able to use openEHR ;D
I think we should also review the "consent" mechanisms we have, as 
they probably should also be tweaked to comply with GDPR.


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

Re: Recommended versioning strategy for Templates

[Pablo Pazos]

In the EHRServer we use that approach, template ids have a version number
and language:
https://github.com/ppazos/cabolabs-ehrserver/wiki/Template-Management-(from-EHRServer-v1.3)

But that is not related to querying.

On Sat, Sep 1, 2018 at 2:21 PM Ian McNicoll  wrote:

> We have informally started to add major version number to our template
> names. Our assumption is that major and minor changes to any component,
> which are not constrained out, should bubble-up to the template. e.g if we
> switched from blood_pressure.v1 to blood_pressure.v2 that would require a
> template major change. OTOH if we went from blood_pressure.v1.1 -> 1.2 but
> none of the 1.2 changes impacted the template we would not change the
> template minor version.
>
> Not sure if that is fully thought through but it follows the spirit of the
> archetype id scheme, I think.
>
> Ian
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
>
> On Sat, 1 Sep 2018 at 18:12, Pablo Pazos  wrote:
>
>> In the EHRServer the implementation of queries allow to express a
>> specific version of an archetype a.b.v1 or all versions a.b.*
>>
>> We don't use filters based on templates yet.
>>
>> Not sure how that is implemented in AQL but maybe there is a matches
>> operation that can match a regex for any archetype version.
>>
>> On Sat, Sep 1, 2018 at 2:03 PM Thomas Beale 
>> wrote:
>>
>>> Dileep,
>>>
>>> the Archetype Identification specification
>>>  may
>>> provide some answers. It undoubtedly needs further development in this area.
>>>
>>> - thomas
>>>
>>> On 01/09/2018 15:04, Dileep V S wrote:
>>>
>>> Hi,
>>>
>>> As an EHR solution evolves, the templates also tend to evolve to an
>>> acceptable level, especially since the archetypes themselves are evolving.
>>> However, all the data recorded using different versions of the OPT should
>>> remain consistently and easily query-able with out the AQL becoming overly
>>> complex and difficult to manage.
>>>
>>> So is there any best practices in versioning the templates as they
>>> evolve so that the incremental evolution does not break the AQLs. The
>>> question is do we use the OPT filename(visually identifiable), Name filed
>>> in template properties or any of the fields in authorship metadata for
>>> indicating the template version?
>>>
>>> Secondly, is there any template best practices document?
>>>
>>>
>>>
>>> --
>>> Thomas Beale
>>> Principal, Ars Semantica 
>>> Consultant, ABD Project, Intermountain Healthcare
>>> 
>>> Management Board, Specifications Program Lead, openEHR Foundation
>>> 
>>> Chartered IT Professional Fellow, BCS, British Computer Society
>>> 
>>> Health IT blog  | Culture blog
>>>  | The Objective Stance
>>> 
>>> ___
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>>
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>>
>>
>>
>> --
>> *Ing. Pablo Pazos Gutiérrez*
>> pablo.pa...@cabolabs.com
>> +598 99 043 145
>> skype: cabolabs
>> Subscribe to our newsletter 
>> 
>> http://www.cabolabs.com
>> https://cloudehrserver.com
>>
>> ___
>> 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
>


-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter 

http://www.cabolabs.com
https://cloudehrserver.com
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: GDPR and OpenEhr.

[Karsten Hilbert]

On Sat, Sep 01, 2018 at 07:57:31PM +0200, Diego Boscá wrote:

> If a patient uses a private health provider then he has the right of taking
> all that information and move to another provider. In that case he will
> want a hard-delete of data.

Indeed they will want that, but there is no absolute right
for a hard-delete (not that I personally like that fact). As
I said, in Germany, that right currently only takes effect
after 30 years (that absolute right). In the meantime,
however, there's a right for sealing against access.

Karsten
-- 
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

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

Re: GDPR and OpenEhr.

[Diego Boscá]

If a patient uses a private health provider then he has the right of taking
all that information and move to another provider. In that case he will
want a hard-delete of data. And I hope private health providers are also
able to use openEHR ;D
I think we should also review the "consent" mechanisms we have, as they
probably should also be tweaked to comply with GDPR.

El sáb., 1 sept. 2018 a las 19:25, Ian McNicoll ()
escribió:

> Hi Bert,
>
> There are certainly some implementations that allow for hard-deletes of
> compositions and Ehrs. This is a complex area as GDPR does not confer an
> absolute right for medical info to be forgotten (as I understand it). It
> does allow for copies of the record to be retained for medico-legal
> purposes.
>
> However, in our cloud-provider setting, we absolutely need to be able to
> hard delete Ehrs, as people may simply want to switch CDR providers. As a
> data processor, we have no right to keep t record, as long as it is
> available via another provider.
>
> Ian
>
> Dr Ian McNicoll
> mobile +44 (0)775 209 7859
> office +44 (0)1536 414994
> skype: ianmcnicoll
> email: i...@freshehr.com
> twitter: @ianmcnicoll
>
>
> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
> Director, freshEHR Clinical Informatics Ltd.
> Director, HANDIHealth CIC
> Hon. Senior Research Associate, CHIME, UCL
>
>
> On Sat, 1 Sep 2018 at 14:52, Bert Verhees  wrote:
>
>> OpenEhr does not really allow to delete data, only logical deletion (mark
>> as deleted), but GDPR demands the right of the patient to be forgotten.
>>
>> Is there some change expected in the specs for compliance to GDPR, or was
>> this already implemented?
>>
>> We had this discussion, slightly different, about ten months ago but no
>> conclusion if I recall well
>>
>> Sorry if I missed a message about this.
>>
>> Thanks
>> Bert Verhees
>> ___
>> 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
>


-- 

[image: VeraTech for Health SL] 

[image: Twitter]   [image: LinkedIn]
 [image: Maps]


Diego Boscá Tomás / Senior developer
diebo...@veratech.es
yamp...@gmail.com

VeraTech for Health SL
+34 654604676 <+34%20654604676>
www.veratech.es

Su dirección de correo electrónico junto a sus datos personales forman
parte de un fichero titularidad de VeraTech for Health SL (CIF B98309511)
cuya finalidad es la de mantener el contacto con usted. Conforme a La Ley
Orgánica 15/1999, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y, en su caso oposición, enviando una solicitud
por escrito a verat...@veratech.es.
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: AQL on specific list of compositions

[Karsten Hilbert]

Thomas,

sorry for the late reply.

> Out of interest, is there a diagram or other GNUmed documentation /
> explanation of all this. It's pretty close to what I think openEHR is or
> should be doing; you have formalised more of this than we have so far, so
> it's good to have some reference points available.

Some details are in my head, but the big picture on the Wiki,
say, in the User Guide:

http://wiki.gnumed.de/bin/view/Gnumed/GmManualBasicEmrConcept

The reason this aligns fairly well with the thinking
in OpenEHR is that I've been following this list for
far too long :-)

Regards,
Karsten
-- 
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

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

Re: GDPR and OpenEhr.

[Karsten Hilbert]

On Sat, Sep 01, 2018 at 06:24:22PM +0100, Ian McNicoll wrote:

> There are certainly some implementations that allow for hard-deletes of
> compositions and Ehrs. This is a complex area as GDPR does not confer an
> absolute right for medical info to be forgotten (as I understand it). It
> does allow for copies of the record to be retained for medico-legal
> purposes.

The latter reason for retention would have a hard limit of 30
years in Germany.

Karsten
-- 
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B

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

Re: GDPR and OpenEhr.

[Ian McNicoll]

Hi Bert,

There are certainly some implementations that allow for hard-deletes of
compositions and Ehrs. This is a complex area as GDPR does not confer an
absolute right for medical info to be forgotten (as I understand it). It
does allow for copies of the record to be retained for medico-legal
purposes.

However, in our cloud-provider setting, we absolutely need to be able to
hard delete Ehrs, as people may simply want to switch CDR providers. As a
data processor, we have no right to keep t record, as long as it is
available via another provider.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll


Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL


On Sat, 1 Sep 2018 at 14:52, Bert Verhees  wrote:

> OpenEhr does not really allow to delete data, only logical deletion (mark
> as deleted), but GDPR demands the right of the patient to be forgotten.
>
> Is there some change expected in the specs for compliance to GDPR, or was
> this already implemented?
>
> We had this discussion, slightly different, about ten months ago but no
> conclusion if I recall well
>
> Sorry if I missed a message about this.
>
> Thanks
> Bert Verhees
> ___
> 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: Recommended versioning strategy for Templates

[Ian McNicoll]

We have informally started to add major version number to our template
names. Our assumption is that major and minor changes to any component,
which are not constrained out, should bubble-up to the template. e.g if we
switched from blood_pressure.v1 to blood_pressure.v2 that would require a
template major change. OTOH if we went from blood_pressure.v1.1 -> 1.2 but
none of the 1.2 changes impacted the template we would not change the
template minor version.

Not sure if that is fully thought through but it follows the spirit of the
archetype id scheme, I think.

Ian

Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: i...@freshehr.com
twitter: @ianmcnicoll


Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
Director, freshEHR Clinical Informatics Ltd.
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL


On Sat, 1 Sep 2018 at 18:12, Pablo Pazos  wrote:

> In the EHRServer the implementation of queries allow to express a specific
> version of an archetype a.b.v1 or all versions a.b.*
>
> We don't use filters based on templates yet.
>
> Not sure how that is implemented in AQL but maybe there is a matches
> operation that can match a regex for any archetype version.
>
> On Sat, Sep 1, 2018 at 2:03 PM Thomas Beale 
> wrote:
>
>> Dileep,
>>
>> the Archetype Identification specification
>>  may
>> provide some answers. It undoubtedly needs further development in this area.
>>
>> - thomas
>>
>> On 01/09/2018 15:04, Dileep V S wrote:
>>
>> Hi,
>>
>> As an EHR solution evolves, the templates also tend to evolve to an
>> acceptable level, especially since the archetypes themselves are evolving.
>> However, all the data recorded using different versions of the OPT should
>> remain consistently and easily query-able with out the AQL becoming overly
>> complex and difficult to manage.
>>
>> So is there any best practices in versioning the templates as they evolve
>> so that the incremental evolution does not break the AQLs. The question is
>> do we use the OPT filename(visually identifiable), Name filed in template
>> properties or any of the fields in authorship metadata for indicating the
>> template version?
>>
>> Secondly, is there any template best practices document?
>>
>>
>>
>> --
>> Thomas Beale
>> Principal, Ars Semantica 
>> Consultant, ABD Project, Intermountain Healthcare
>> 
>> Management Board, Specifications Program Lead, openEHR Foundation
>> 
>> Chartered IT Professional Fellow, BCS, British Computer Society
>> 
>> Health IT blog  | Culture blog
>>  | The Objective Stance
>> 
>> ___
>> openEHR-technical mailing list
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>
>
> --
> *Ing. Pablo Pazos Gutiérrez*
> pablo.pa...@cabolabs.com
> +598 99 043 145
> skype: cabolabs
> Subscribe to our newsletter 
> 
> http://www.cabolabs.com
> https://cloudehrserver.com
>
> ___
> 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: Recommended versioning strategy for Templates

[Pablo Pazos]

In the EHRServer the implementation of queries allow to express a specific
version of an archetype a.b.v1 or all versions a.b.*

We don't use filters based on templates yet.

Not sure how that is implemented in AQL but maybe there is a matches
operation that can match a regex for any archetype version.

On Sat, Sep 1, 2018 at 2:03 PM Thomas Beale 
wrote:

> Dileep,
>
> the Archetype Identification specification
>  may
> provide some answers. It undoubtedly needs further development in this area.
>
> - thomas
>
> On 01/09/2018 15:04, Dileep V S wrote:
>
> Hi,
>
> As an EHR solution evolves, the templates also tend to evolve to an
> acceptable level, especially since the archetypes themselves are evolving.
> However, all the data recorded using different versions of the OPT should
> remain consistently and easily query-able with out the AQL becoming overly
> complex and difficult to manage.
>
> So is there any best practices in versioning the templates as they evolve
> so that the incremental evolution does not break the AQLs. The question is
> do we use the OPT filename(visually identifiable), Name filed in template
> properties or any of the fields in authorship metadata for indicating the
> template version?
>
> Secondly, is there any template best practices document?
>
>
>
> --
> Thomas Beale
> Principal, Ars Semantica 
> Consultant, ABD Project, Intermountain Healthcare
> 
> Management Board, Specifications Program Lead, openEHR Foundation
> 
> Chartered IT Professional Fellow, BCS, British Computer Society
> 
> Health IT blog  | Culture blog
>  | The Objective Stance
> 
> ___
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>


-- 
*Ing. Pablo Pazos Gutiérrez*
pablo.pa...@cabolabs.com
+598 99 043 145
skype: cabolabs
Subscribe to our newsletter 

http://www.cabolabs.com
https://cloudehrserver.com
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Re: Recommended versioning strategy for Templates

[Thomas Beale]

Dileep,

the Archetype Identification specification 
 may 
provide some answers. It undoubtedly needs further development in this area.


- thomas


On 01/09/2018 15:04, Dileep V S wrote:

Hi,

As an EHR solution evolves, the templates also tend to evolve to an 
acceptable level, especially since the archetypes themselves are 
evolving. However, all the data recorded using different versions of 
the OPT should remain consistently and easily query-able with out the 
AQL becoming overly complex and difficult to manage.


So is there any best practices in versioning the templates as they 
evolve so that the incremental evolution does not break the AQLs. The 
question is do we use the OPT filename(visually identifiable), Name 
filed in template properties or any of the fields in authorship 
metadata for indicating the template version?


Secondly, is there any template best practices document?




--
Thomas Beale
Principal, Ars Semantica 
Consultant, ABD Project, Intermountain Healthcare 

Management Board, Specifications Program Lead, openEHR Foundation 

Chartered IT Professional Fellow, BCS, British Computer Society 

Health IT blog  | Culture blog 
 | The Objective Stance 

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

Recommended versioning strategy for Templates

[Dileep V S]

Hi,

As an EHR solution evolves, the templates also tend to evolve to an
acceptable level, especially since the archetypes themselves are evolving.
However, all the data recorded using different versions of the OPT should
remain consistently and easily query-able with out the AQL becoming overly
complex and difficult to manage.

So is there any best practices in versioning the templates as they evolve
so that the incremental evolution does not break the AQLs. The question is
do we use the OPT filename(visually identifiable), Name filed in template
properties or any of the fields in authorship metadata for indicating the
template version?

Secondly, is there any template best practices document?

regards
Dileep V S
*Founder*
HealtheLife Ventures LLP
m: +91 9632888113
a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
w: healthelife.in  e: dil...@healthelife.in
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

GDPR and OpenEhr.

[Bert Verhees]

OpenEhr does not really allow to delete data, only logical deletion (mark as 
deleted), but GDPR demands the right of the patient to be forgotten.

Is there some change expected in the specs for compliance to GDPR, or was this 
already implemented? 

We had this discussion, slightly different, about ten months ago but no 
conclusion if I recall well

Sorry if I missed a message about this. 

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

Re: AQL support for an array of ehr_id

[Dileep V S]

thanks

regards

Dileep V S
*Founder*
HealtheLife Ventures LLP
m: +91 9632888113
a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
w: healthelife.in  e: dil...@healthelife.in

On Sat, Sep 1, 2018 at 12:57 PM, Seref Arikan <
serefari...@kurumsalteknoloji.com> wrote:

> The matches statement is part of Aql specification
>
>
> On Friday, August 31, 2018, Dileep V S  wrote:
>
>> Dear Ian,
>>
>> Thanks. Is this part of the AQL spec or a feature that THinkEhr has
>> implemented?
>>
>> Given the emerging importance of patient consent, given the GDPR and
>> similar rules coming our across the world (DISHA in India), this may become
>> a basic requirement in any EHR systems of the future. A static mapping of
>> an EHR to the creator organization, as is normal in provider centric
>> systems, may not be good enough.
>>
>> regards
>>
>>
>> Dileep V S
>> *Founder*
>> HealtheLife Ventures LLP
>> m: +91 9632888113
>> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
>> w: healthelife.in  e: dil...@healthelife.in
>>
>> On Thu, Aug 30, 2018 at 11:11 PM, Ian McNicoll  wrote:
>>
>>> Hi Dileep - this is supported by THinkEhr...
>>>
>>> SELECT
>>>e/ehr_id/value, a/data[at0001]/events[at0006]/time,
>>>   a/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value,
>>>   a/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value --
>>> diastolic
>>>  FROM EHR e CONTAINS OBSERVATION a[openEHR-EHR-OBSERVATION.bloo
>>> d_pressure.v1]
>>> WHERE e/ehr_id/value MATCHES { 'e241715b-3ca7-435e-a474-718579aadaa2',
>>> '0e7ac1d6-2dc6-40ec-8259-ac9f9a9727d1', 'ed74f788-4bd6-4e47-ab98-21164
>>> 3cc4b0c'}
>>>
>>> Ian
>>> Dr Ian McNicoll
>>> mobile +44 (0)775 209 7859
>>> office +44 (0)1536 414994
>>> skype: ianmcnicoll
>>> email: i...@freshehr.com
>>> twitter: @ianmcnicoll
>>>
>>>
>>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
>>> Director, freshEHR Clinical Informatics Ltd.
>>> Director, HANDIHealth CIC
>>> Hon. Senior Research Associate, CHIME, UCL
>>>
>>>
>>> On Thu, 30 Aug 2018 at 18:23, Dileep V S  wrote:
>>>
 Hi,

 I am not sure if this has been asked before. I am asking again since I
 could not find an answer

 Does AQL support an array of EHRs? In AQL specs i can see examples to
 query any a single EHR and across all EHRs in the system. If I want to
 limit my query to a set of EHRs is it possible using AQL?

 Use case - As part of a dynamic consent management framework, we keep a
 dynamic mapping of EHRs to organizations. This is kept updated based on
 patient consent. So at any time a query is run by an organization, it
 should be limited to the EHRs that it has consent at that point of time.

 regards
 Dileep V S
 *Founder*
 HealtheLife Ventures LLP
 m: +91 9632888113
 a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
 w: healthelife.in  e: dil...@healthelife.in
 ___
 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
>>>
>>>
>>
> ___
> 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: AQL support for an array of ehr_id

[Seref Arikan]

The matches statement is part of Aql specification

On Friday, August 31, 2018, Dileep V S  wrote:

> Dear Ian,
>
> Thanks. Is this part of the AQL spec or a feature that THinkEhr has
> implemented?
>
> Given the emerging importance of patient consent, given the GDPR and
> similar rules coming our across the world (DISHA in India), this may become
> a basic requirement in any EHR systems of the future. A static mapping of
> an EHR to the creator organization, as is normal in provider centric
> systems, may not be good enough.
>
> regards
>
>
> Dileep V S
> *Founder*
> HealtheLife Ventures LLP
> m: +91 9632888113
> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
> w: healthelife.in  e: dil...@healthelife.in
>
> On Thu, Aug 30, 2018 at 11:11 PM, Ian McNicoll  wrote:
>
>> Hi Dileep - this is supported by THinkEhr...
>>
>> SELECT
>>e/ehr_id/value, a/data[at0001]/events[at0006]/time,
>>   a/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value,
>>   a/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value --
>> diastolic
>>  FROM EHR e CONTAINS OBSERVATION a[openEHR-EHR-OBSERVATION.bloo
>> d_pressure.v1]
>> WHERE e/ehr_id/value MATCHES { 'e241715b-3ca7-435e-a474-718579aadaa2',
>> '0e7ac1d6-2dc6-40ec-8259-ac9f9a9727d1', 'ed74f788-4bd6-4e47-ab98-21164
>> 3cc4b0c'}
>>
>> Ian
>> Dr Ian McNicoll
>> mobile +44 (0)775 209 7859
>> office +44 (0)1536 414994
>> skype: ianmcnicoll
>> email: i...@freshehr.com
>> twitter: @ianmcnicoll
>>
>>
>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
>> Director, freshEHR Clinical Informatics Ltd.
>> Director, HANDIHealth CIC
>> Hon. Senior Research Associate, CHIME, UCL
>>
>>
>> On Thu, 30 Aug 2018 at 18:23, Dileep V S  wrote:
>>
>>> Hi,
>>>
>>> I am not sure if this has been asked before. I am asking again since I
>>> could not find an answer
>>>
>>> Does AQL support an array of EHRs? In AQL specs i can see examples to
>>> query any a single EHR and across all EHRs in the system. If I want to
>>> limit my query to a set of EHRs is it possible using AQL?
>>>
>>> Use case - As part of a dynamic consent management framework, we keep a
>>> dynamic mapping of EHRs to organizations. This is kept updated based on
>>> patient consent. So at any time a query is run by an organization, it
>>> should be limited to the EHRs that it has consent at that point of time.
>>>
>>> regards
>>> Dileep V S
>>> *Founder*
>>> HealtheLife Ventures LLP
>>> m: +91 9632888113
>>> a: 106, Innovation Centre, IIIT, Electronics City, Bangalore 560100
>>> w: healthelife.in  e: dil...@healthelife.in
>>> ___
>>> 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
>>
>>
>
___
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org