Hi all,
Has anyone got an example of implementing the extended elements of feeder_audit in JSON FLAT? e.g. _feeder_audit_details/time. I’m going around in circles on the correct syntax…
For me, the best documentation of the Flat format is the one from EHRbase.
It should be like this:
conformance_observation/_feeder_audit/feeder_system_audit|time": "2021-12-21T16:02:58.0094262+01:00"
https://docs.ehrbase.org/en/latest/08_flat/01_data_types/index.html#feeder-audit
2 Likes
Ignore me!! I RTFM…
originating_system_audit|time
Nice.
I gotbthere as you were responding. Although i have found a mismatch between Better and ehrbase. Provder for example does not work with ehrbase as far as i can make out
Do the guys a favour and make a github issue at ehrbase.
Also @pablo is the conformance framework also testing the flat format ?
1 Like
As soon as these format flavors get standardized, they should be included in the conformance test suites, until then, only canonical formats are part of the test suites.
@johnmeredith Note this format is not completely standardized yet. Recommendation is to use the canonical format for which we have JSON and XML schemas.
This may be your personal recommendation, but typically there is no issue using the WebTemplate formats.
1 Like
Though that is implementation dependent and not yet formal part of the specs and current draft spec needs some love.
Will do so today.
1 Like
We need it standardised asap. There is a reasonably large overhead in translating them into the sort of work that dev teams do with us. Mvc c# applications and providing a conduit for them is a priority for me.
1 Like
It depends on the main implementers to harmonize their differences, basically EHRBase and Better.
That is why canonical formats are the safest right now:
- those formats are part of the spec
- been implemented and tested thoroughly between vendors
- supported by most CDRs and tools from different vendors
- we have canonical JSON and XML schemas to automated generation, validation and processing
- schemas are closely based on the reference model
I don’t see why a developer can’t use the canonical formats or any advantage of using a different format. At the end I think it’s and arbitrary decision though. That’s OK as long as it’s an informed and conscious technical decision.
Safe does not equal easy. All this has risk but its clear to me from a Board persepctive that we have to take the cognitive load out of adoption. Json flat + web templates are key.
2 Likes
Im a little bit confused, i maybe got something wrong, is the tool for the community ?
Or to test the conformance to your solution.
If the tool is there to test openEHR conformance, a support of flat would be awesome.
Adoption is a different discussion, we can get into that though.
Everyone here has an opinion about adoption, I don’t think JSON flat + web templates have anything to do with that, technically, conceptually or philosophically.
Then what is easy or not easy, depends on who are you talking with. Today you can do this with tools freely available:
- create/use archetypes based on your needs/domain
- create canonical operational templates based on your needs/domain and your archetypes
- automatically generate sample JSON and XML canonical compositions with one click (check https://toolkit.cabolabs.com/)
- use those examples to map your app data (can be as easy as a string replacement)
- commit those canonical JSON/XML compositions with your data to any openEHR CDR
- create queries and get data back
- automatically generate forms and other UIs based on canonical operational templates
Seriously, where is the not “easy” part? With a simple domain, like vital signs, you can get that flow done in minutes.
IMHO this is safe an easy as you can wish. I don’t see any extra cognitive load than learning the specs that we are working with. If it’s not easy for someone, maybe there is a gap somewhere else, like a dev that gets this workflow on his/her lap and has to implement it without understanding what is openEHR at all. If that’s the case, then a little training would be the best option.
But again, choosing something else over canonical is a personal preference. The format is not so important, what’s important is understanding what’s we are doing as devs.
The conformance framework doesn’t depend on any implementation. The idea is to test any system, and not only CDRs.
I wrote extensively about that, it’s all defined in the attached document on this article CaboLabs Blog - openEHR Conformance Framework
The conformance verification process is focused on current approved specs, not on proposals or draft specs, so there won’t be any work on that area until flat gets standardized/harmonized by their implementers: EHRBase and Better (basically because we can’t say what’s right or wrong until the whole format gets standardized). AFAIK no other companies use that format or they use their own formats if not using canonical ones. Remember the flat format was a custom solution by Better for their tools, then adopted by EHRBase but the implementation was not 100% equivalent last time I worked with EHRBase. I don’t know what’s the current status though. I guess @birger.haarbrandt might now.
You are talking about THE conformance verification process without having a clear mandate for that. So it’s your idea to test any system. With HiGHmed and later vita, we developed the framework for automated testing and one further area of application should be procurement processed to clarify point out which systems are actually supporting things like openEHR REST, AQL, WebTemplates etc.
Unfortunately we are currently a bit too busy with other stuff, but there is shared interest to move the implementation of a conformance testing framework forward.
2 Likes
Here is some violent agreement. You are all right.
Next step is conforming.
Progression needs leeway but conformance needs adherence.
@Bostjan_Lah and @stefan.schraps have our marching orders. Lets do this.
1 Like
Progress with the board is slow but we had talks about it and there is interest of moving forward on THE conformance verification process. What I did was just formalize the process, the architecture, the test definitions and the test implementation.
Next step is actually to have a draft spec for the conformance, with an updated process, architecture, definitions and implementation, which is part of the SEC work, though I didn’t found time to formally propose a WG for that yet, though it’s in the agenda.
To be honest, the whole conformance formalization was my idea after my contract with HiGHmed finished, I started formalizing the whole conformance framework (link above), extending the scope. Most proposals for conformance were incomplete or just focused on test cases not on a whole comprehensive set of rules for everyone to use as guides for validating implementations, or just focused on CDRs.
In the talk I gave about this topic in the NL event (the presentation is here GitHub - ppazos/openehr-conformance-verification: Conformance verification framework or openEHR implementations) it was mentioned that after we have the conformance specs updated, we need to focus on helping both sides of procurements and on software certification. Though, since we have actually zero resources behind this work, it’s impossible to work on a conformance verification components of specs that are not approved / proposals / drafts. Is just that, so if we get that spec actually reviewed by it’s implementers, and hopefully get some support from openEHR or from interested parties, we surely will add components to the conformance spec to verify other formats. I don’t have any issues with that and I hope Better and Vita can move those specs forward together.
There is a secondary orthogonal discussion here about if those other non canonical formats are really easier to use than canonical ones, I don’t see any clear argument why one should be considered simpler or better than the other, it’s just preference, just mentioned the canonical one we have a whole set of specs and tools to go full cycle in no time, thus the argument of perceived simplicity is just that, perception, might be because it’s just a list of key/values and not a tree, might be because there are less bytes used in some cases, I’m not sure. Now I’ll just shut up about this secondary discussion 
John had a very specific implementation detail about FLAT. So for something you say you don’t care about, you appear somewhat invested to convince the audience to not use FLAT.
1 Like