Link between goals and other clinical concepts

Clinical (archive)
21

I missed a part of the discussion, but maybe I get the point, or I see my hobbyhorse everywhere. :wink:

I have been thinking about this some time, and I started a few times a discussion about this subject. But I must say, there is not much enthusiasm for this idea on this list.
Let me explain compactly.

Take a look at the EN13606 RM which is already much more generic then OpenEHR. You can model archetypes for it with the LinkEHR archetype-editor.

For a developer, it is nice to have a generic reference model, it can help you create generic code in the application/kernel.
For a domain-modeler (a medical-information-specialist, f.e.) it is nice to have semantics in the reference model. It helps thinking about how to model an archetype for a specific purpose.

There is a way in between, which can serve both groups:
You need to bring order in the chaos of generic CLUSTER_archetypes. You can do a lot with archetype-slots with defined reg-expressions, so in this way, the generic archetypebase canconsolidate in an information-model which can be used by the domain-modeler.
This information-model needs to be defined, controlled and documented.

Then you reach the area of proprietary.
Domain-modelers need besides adapting the reference model, conforming to your defined proprietary information model.

And, on second thought, anyway, you need to adapt a good message-model, because not the whole world will run OpenEHR.

The nice thing about two level modeling is that, this is all possible.

good luck
Bert

22

Hi Bert,

I assume you are talking about those types of semantics that are currently in the openEHR reference model like observation and instruction.

This argument has been around for a while. My issue with this is that if you start to control some way of modelling generic archetypes for these types of semantic structures, then you are in exactly the same space as doing it in the reference model but without the same level of governance or control. CIMI have also suggested this approach. This is likely to be more difficult for developers as there is a much higher likelihood of multiple types of instructions/actions/observations that will need to be dealt with rather than one reference model based way of doing it.

I actually would contend that these structures are not domain specific, although they may have domain specific names. We want the reference model to tell us how to construct compositions and entries as well as a consistent way of defining tables or tree structures so that software can be written once to handle all possibilities. These openEHR constructs that seem to cause such controversy, just make explicit things that are going to be modelled over and over in the same way as these other things. If we don't put these things in the reference model, then we will have to accept that there will be an increased variability in the way that they are modelled which is likely to make software more complex.

Its an argument/discussion that we will continue to have I suspect.

Regards Hugh

. -----Original Message-----

23

Hi Hugh,

It is indeed a discussion which runs for several years.
I mentioned 13606 but it can also be done in OpenEHR. OpenEHR also has lists, trees, clusters, elements, all derived from Locatable, thus archetypeable.

So you can define (what I call) an information model, based on the generic structures in OpenEHR.

Say you want to conform to HISA, is that possible in the Composition-package? I am not sure, I read it once, some years ago, and I saw some problems, say (imagine) HISA will conform more in direction of ContSys, how do you handle this in the OpenEHR composition-package, and we all know, it will not stop there. It is an illusion to think that an information model will last for ever.

Maybe there are concurring information models, maybe you want a kernel to support more, simultaneously, maybe you want to write an API to a specific information model?
Imagine HL7, for example, VMR, based on archetypes? I once did that, for a customer. I did not write an API for that, just the archetypes, but I could write an API for that.

I am afraid you will find the composition package restrictive. It represents a good information-model, as far as I can judge (it is not my specialty), but is just AN information model. There can be more which are good too.

That is why I think, semantics do not belong in the reference model, but in a constructed archetype/template-based information model.
You could also model the OpenEHR information model, which now resides in the reference model, in such constructed archetype/template-based information model, using only structure-based archetypes.

You say that information models will be defined over and over again. This can happen, but it is, in my opinion, not likely to happen in professional environments where the choice will always be kind of standardized model.

You mention that software will be too complex when a reference model with no semantics is used. I am softwaredeveloper, I think opposite.
I think a kernel should eat any archetype (with valid ADL) and should eat any dataset conforming to an archetype. So, there is no problem. There is no change needed in the kernel.
I think an API can be defined conforming to an information model, which is represented in a set of archetypes. It can do its checks, that is not much of complexity.
I think a screen/report-generator can be build on base of a trust-able set of archetypes/templates, and screen-parts can be used as lego-blocks

And then you find a customer which says: "Yes, we want to do CLEVER-MEDINFO version 2, an information model and API defined in the University of CleverVille, most famous for medical information."
And three months further, it is ready.

As I say many times when talking about this subject: Let thousand flowers bloom.

And don't forget, OpenEHR is just AN information model, it is not THE information model. So, you will need a decent message standard anyway for interoperability.
And for the future, we will not be able to stop it. I think, this what I describe, is going to happen.
Restrictions or Semantics on kernel level will become obsolete for two reasons I can think of now:
- It is not necessary to do that on kernel-level, because it can be done on archetype level.
- It is fixed too much, it is very hard to conform to new standards, it does not stimulate innovation.

Best regards
Bert

Hugh Leslie schreef op 24-6-2014 23:22:

24

Hi Bert,

As ever these are interesting discussions and the 'no semantics' in
the reference model approach has some attractions. I happen to agree
with Hugh that it seems that one way or other, there are a set of
generic semantic constructs which need to be broadly and tightly
adhered to, and controlled at 'reference level' and whether this is
done by using reference archetypes or hard-wired in to the ref. model
is somewhat arbitrary. One of the advantages, for instance, of using a
'reference-level' observation date is that vendors can optimise their
systems, knowing that this will be universally available. Whether this
is an RM attribute or an element of a reference archetype does not
much differ in terms of commitment to stability of that data point.

There is actually very good alignment between Contsys and the openEHR
RM. There are a few places where there is some degree of mismatch and
where having a top-level extension to e.g COMPOSITION or INSTRUCTION
would allow for Contsys-specific attributes to be handled more easily,
but I think this can be simply achieved by adding a top-level CLUSTER
slot to COMPOSITION and ENTRY classes. That way we can bridge the gaps
between different source information models without compromising the
overall approach.

Having said all thta, I think the openEHR implementation and
real-world use has reached a level of practical use where these kind
of discussions are moot. It is going to be up to Industry and other
real-world users to tell us if they want the kind of root-and-branch'
reform that you are advocating. I think we all recognise that there
are gaps in the current RM and things that we can do better but I am
not hearing a major push from the implementer community for the kind
of radical change in approach that you are advocating. For most
people, my impression is that the existing RM is working pretty well.
Certainly not perfect, but I am not sure that the use of reference
archetypes necessarily solves these problem, it just moves them
elsewhere.

I agree re messaging, but again I am not sure that this is a
significant issue for implementers (at least in your terms). openEHR
systems are talking to a variety of messaging formats. If someone
wanted to build a set of archetypes that mimiced CDISC or HISA or
whatever, that could be done using the generic archetype but no-one
has taken that approach so far to my knowledge because openEHR is not
trying to build CDISC or HISA EHR systems internally. It is
deliberately optimised for EHR use.

I am also concious that we have hi-jacked Pablo's original discussion.
Perhaps we should split this into two threads but I will leave that
for Pabl / Bert to resolve!

Ian

25

Hi All,
Based on our experience working with goals and targets in our Care Planning system in Australia, the use of specialised Goals is not viable option from an implementation perspective. The specialisation I am talking about is a little different to what has been discussed so far as we were using templates to constrain the generic goal archetype for a specific type of goal. Therefore, it really relates to the alternative CLUSTER approach also. This worked fine from a modelling perspective but when it came to implementing it in an app, it was a nightmare. We had to have specific code to handle each type of goal (template) but we wanted a solution where we could easily add a new type of goal without needing to do any further coding. This may be a result of the way we build our apps since after many years developing real clinical apps deployed in dozens of hospitals, we have chosen not to use a form generated approach as we do not believe this provides the end user with a great user experience or enable enough control over the application workflows. Perhaps those of you that are smarter have been able to achieve this but I don't think the models should make any assumptions about how one should develop their Application.

What we ended up doing is implementing a generic approach to recording goals and targets that was metadata driven. The metadata is maintained separately from the goal archetype and drives the way the application presents and captures data about each type of goal (OK, perhaps we do have a little bit of form generation, but it is separate from the archetype and only were it makes sense). You might say that this metadata should be in the archetype for all to use, but we come back to the usual argument that archetypes is just a model for what can be recorded about a concept, not the business rules specific to a particular use case, application, project or jurisdiction.

As someone suggested, I think this is where GDL starts to kick in and we should stop trying to overload the functionality of archetypes with all this business rule (guideline) semantics.

Regards

Heath

26

Hi all,

I'm just going to chip in here because we see a lot of discussion about drawbacks of the openEHR ENTRY types, but not a lot of endorsement. After 8 years of modelling archetypes, I find that the ENTRY classes work really well, and this is subsequently borne out in implementation. For example, the ACTIONs are an extremely elegant and practical class, although complex to implement. The OBSERVATIONs I model, especially related to device capture, can be extremely complicated related to State, Protocol and Events. It is not very often I find a requirement that cannot be managed within these structures.

They aren't perfect, but every time I have to model a complex archetype the power of the RM plus the ENTRY specific attributes makes the modelling a relative breeze. I only need to worry about the clinical content itself.

Keep in mind, that I am speaking as a *non-technical clinician modeller*. And in openEHR, I will always argue that the most appropriate archetypes will be developed by the clinical community. Models developed by technical modellers are structured quite differently, not necessarily representing the real clinical world and often trying to define abstract patterns that don't exist in the clinical space. The barrier to entry for non-technical modellers to a 13606 or CIMI RM is much greater. We will see the outcome in the archetypes produced, believe me.

So anything that ensures that the RM is represented consistently and allowing consistent modelling approach for clearly identifiable clinical data patterns. In reality I don't consider the ENTRY classes to carry semantics, and often the names are misleading - perhaps they should have been named Model A, B, C etc.

My 2c

Heather

27

Hi Heath,

That is very interesting. Can you give an example of the kind of
metadata you are storing externally? I don't see the problem per-se
with having term-driven models but perhaps that is because a UK
perspective is always a bit more comfortable with this approach, but I
also understand how that also has a number of limitations once you
move away from labellling the goal and any specific targets.

I modelled a few Goals/targets in the SemanticHealthNet Heart failure
summary and using SNOMEDCT seemed to work reasonably well but I
suspect your requirements were a bit more complex.

http://www.openehr.org/ckm/#showTemplate_1013.26.14

Ian

Ian

28

I might need Adam to help with the specifics but from memory, since we implemented a problem oriented care plan, we had a set of goals that may be relevant for a specific problem, the targets relevant to a goal, the type of data representation of the target (e.g text, single value, range, less than/greater than) and the kind of activities (instructions) that are relevant to achieving the goal target. Can't remember if there is a reference to the observation value that would be used to evaluate the target variance.

As you can see this is more than clinical model semantics, but with this we are able to drive the app to capture this data and populate the generic goal archetype data. Some of this could probably be represented using GDL, but I haven't explored this yet.

Regards

Heath

29

Hi all,

I'm just going to chip in here because we see a lot of discussion about drawbacks of the openEHR ENTRY types, but not a lot of endorsement. After 8 years of modelling archetypes, I find that the ENTRY classes work really well, and this is subsequently borne out in implementation. For example, the ACTIONs are an extremely elegant and practical class, although complex to implement. The OBSERVATIONs I model, especially related to device capture, can be extremely complicated related to State, Protocol and Events. It is not very often I find a requirement that cannot be managed within these structures.

Hi Heather,

If you read well I state more then one time that I think that the OpenEHR information model, this includes also the ENTRY-model, is good.

The discussion is about if the definition of the information model should be in the reference model. Of course, the reference model will always give a base, so there will always be some semantics in it, but the question is, how much semantics should be in there, and, even more important, which semantics.

It is not about your requirements, I think most medical information models can meet most of your requirements. The point is that there are more information models, and you cannot use them when you use OpenEHR. One reason for this is because of the semantic structures openEHR defines on the reference model.

Bert

30

Hi Ian,

As I come to think about it, it is a bit different, then I thought yesterday it was.

Because a Reference Model, HISA, or some HL7 document, or OpenEHR, they can be mimicked by a Reference Model without semantics.
But it is only the structure you mimic, and that works fine.

But is you also want to mimic the attribute-names, then a generic Reference Model will not do.

There are two ways of solving this

- Leave the attribute-names as they are in the generic Reference Model, and use the ontology-text to define the attribute-name from the information model to mimic.
In this case, one generic Reference Model, can mimic almost all possible Reference Model. The problem is when querying, people writing the query will use the wrong attribute-names and mapping needs to be done.

- Have your kernel processing more Reference Models simultaneously. A Reference Model mostly can be expressed in an XML Schema. Check archetypes against these XML Schema's In this way, you do not only mimic the structure of a required Reference Model, but also the attribute-names.

It is, of course, possible to query more Reference Models simultaneously. Not one to cover the complete medical field, but one for every field.

Bert

31

well there are always ‘semantics’ in an information model, no matter how generic. It’s just a question of how specific. The DvQuantity class has some very general semantics, which most people accept, and which can be mostly converted in and out of PQ and other ‘competing’ types. The Composition class is defined in 13606 and openEHR to do one job - act as a container for data captured during the same health event. It doesn’t do all jobs. There is no reason we would not add other classes in the future to openEHR to handle other general categories of data, either at a similar level as Composition, or finer levels - just like we would add a new data type if we need it. well, you could get some way. Developers like the structures in Observation and Action and Instruction, because they can be programmed once in Java, Ruby, Python, C#, … etc and they just work. No archetypes to worry about there, and yet they take care of a lot of quite complex data like differential time-series, multi-drug orders and so on. If you try to replicate all those details as reference archetypes, you’ll get some of it done, but since you can’t create generic (templated) types or use multiple inheritance (at this stage, at least) in ADL/AOM, there are going to be limitations. Solving that means upgrading ADL to have the power of a language like C++. I’m not sure if that’s what we should be doing. Right now, displaying a time-series of heart rate v treadmill speed over 15 mins is dead simple in openEHR - the data structures are all there. Doing that in even 13606 requires: The one thing we did not do very successfully in openEHR is to preserve the generic form of ENTRY; this is what let’s the ‘thousand flowers bloom’, but doesn’t prevent proper reference structures being in the RM either. In the near future we will fix this. - thomas

32

The Composition class is defined in 13606 and openEHR to do one job - act as a container for data captured during the same health event. It doesn’t do all jobs. There is no reason we would not add other classes in the future to openEHR to handle other general categories of data, either at a similar level as Composition, or finer levels - just like we would add a new data type if we need it.

This is exactly the problem why I mention it. Because OpenEHR is in the RM, and not in archetypes, people using it, must wait for you or others to add a new class. It makes them dependent. At that moment, they experience an information-lock-in.

There is another problem also, because OpenEHR as RM guarantees to remain backwards compatible, it cannot remove classes from the RM.
This means there must be some provision to handle redundancy in data-definition which can occur when new classes are added. Redundancy means, more paths to store data of the same semantic meaning. The start of big trouble.

I learned a lesson, a long time ago, and I see that this is still a valuable lesson.The lesson was: Never put semantics in the database design, put it in the data.
(it is an often made mistake to ignore this lesson)

I think more or less it can be applied to this discussion.
You can in analogy regard the Reference Model as database-design and the archetypes as semantics to explain the data.
The big trouble which can occur in redundancy in data-definition is because of having semantics in database-definition level.

I am still not aware of a good reason to create a semantic rich RM, while there are enough possibilities to link the data to the semantics via archetypes.

You could also model the OpenEHR information model, which now resides in the reference model, in such constructed archetype/template-based information model, using only structure-based archetypes.

well, you could get some way. Developers like the structures in Observation and Action and Instruction, because they can be programmed once in Java, Ruby, Python, C#, … etc and they just work. No archetypes to worry about there, and yet they take care of a lot of quite complex data like differential time-series, multi-drug orders and so on.

Information must be the purpose of an EHR-definiton, not solving developer-issues.

In my case, f.e., I don’t even have classes representing a Reference Model. I don’t need them. Archetypes are the thing I worry about. Data must conform the constraints in the RM and in the archetypes.
For my kernel it is the same if a dataset represents an ItemTable, an Observation or a Person.
They are treated the same way,

  • they are validated on XMLSchema ((RM-validation) f.e. an Observation cannot live on its own)
  • and on Schematron (archetype-validation)
  • and stored as XML,
  • and can be queried by AQL or XPath/XQuery.

Maybe this was a problem in the year 2004, in that time we saw all developers mimicking the Reference Model in class-schema’s of their favorite language. Me too, but not anymore.
So you solved a problem that I do not have.

Do other people have this problem? Are they relying on RM-classes to process datasets?

If you try to replicate all those details as reference archetypes, you’ll get some of it done, but since you can’t create generic (templated) types or use multiple inheritance (at this stage, at least) in ADL/AOM, there are going to be limitations. Solving that means upgrading ADL to have the power of a language like C++. I’m not sure if that’s what we should be doing.

I am not sure about this, I don’t see the multiple inheritance.

As I see it on a quick glance (just an idea), there must be base-archetypes, a base archetype would represent the base class structures, as you can find them now in the RM.
I think a new attribute would be needed to the CComplexObject-items. It would be the attribute rmtype.
Like this
ITEM_LIST[archetype_node_id=at0001, rmtype=“COMPOSITION”] matches …
etc etc

This is no problem in using attributes because they are easy to query. The kernel now also relies on the attribute archetype_node_id=at0001, without any problem.

Right now, displaying a time-series of heart rate v treadmill speed over 15 mins is dead simple in openEHR - the data structures are all there. Doing that in even 13606 requires:

  • defining reference archetypes for time-series data, where the events can have secondary state i.e. each event has a primary datum like heart rate, and ‘state’ data like exertion (treadmill speed)
  • writing software that knows how to transpose the Cluster/Element structures into a logical time-series, and figure out what is the main datum, what is the state, what are the widths of every event and so on
  • remember, there won’t be any Java / Ruby / Python /.. classes to do this - you have to do it all manually.

I don’t understand why you bring up this subject.

I stated a few times that OpenEHR is a fine information model, and maybe there are some difficulties in EN13606, that may be true.
I also wrote that designing medical information models is not my specialty.
So I will not easy say about an medical information model if it is good or bad. I can only judge it on basic-design-rules.

The point is that you don’t have to choose if you use generic kernel.
You can use multiple in archetypes-based reference models to validate and store and query data. You can allow certain parts of an healthcare organization, without any technical provision, to implement new ideas about medical data structures, maybe necessary for specific treatment.

As I see the battle-field of medical information model-designers, the war is not over yet, and it will never be. There will be great ideas which need an own Reference Model.

Being prepared for that is a good thing.

Best regards
Bert

33

anyone can make a local change, test it, and propose the change to the RM. And anyone can make ‘reference archetypes’ as you proposed earlier. It’s encouraged. I think it all depends on what the new classes are. We aren’t likely to add many, and they are all generic, i.e. semantically invariant classes. There are no domain specifics in the RM, only general concepts like the classes you see today. New classes would need to be at the same level of generality. that’s the foundational basis of openEHR :wink: there isn’t a semantic-rich RM, there is an RM that has only semantics that are general across health, and I would argue much of observational science. As you know, there are no lab results, prescriptions, ECGs or any of the 1000s of other clinical things in the RM - those things are all archetypes. What is there are semantics that appear to be invariant across the domain - ‘Observation’ and so on. Time seems to have proved this a reasonable choice. well - that depends on what the developer issues are. If a badly designed or too-simple RM causes developers to write software that generates non-interoperable data, then it’s a serious data problem. well I guess that means you are using a different category of architecture. But if you are using any archetype specialisations, then you are actually using more or less the same architecture, just one level up. How do you want to solve the problem of having a standard representation of orders, or time-series data, across all countries, so that re-usable software can be written? You can only do that with wide agreement on those semantics, wherever they are specified - in an RM, or in some layer of archetypes. this is certainly possible, but just making easy things needlessly hard in my view. You can do all this, or you can just use the reference model and get it all for free. that’s also easy to do with reference models. There are many reference models , to plug into a kernel. sure, but like I said, this is just the same problem moved up one level. At some point, you still have to write classes with the semantics of things like Observation or Composition or whatever. Otherwise you can’t get the data on the screen, or compute with it in any meaningful way. - thomas

34

What is to stop you using them? I have 5 reference models loaded into the ADL Workbench right now. Building a kernel to use them wouldn't be hard.

- thomas

35

Hi Bert

All good points and I think it comes down to what your focus is. I think you are focussed on one information model that could be used to represent any of the other current information models out there including openEHR. We are focussed on interoperability of information in the health space and making that as easy and reliable as possible for every situation. I think it's easy to see that depending on where your focus is, there is going to be a different requirement for the reference model.

Regards Hugh

36

Hi al,

Many roads lead to Rome.

At the extremes I can envisage:

  • A Reference Model that makes many recurring patterns part of the RM. Observation, Evaluation, Instruction and Action are examples. And leaving a few details to the archetypes.
    (Remember the first (1998) HL7v3 RIM’s where on several square meters of paper one needed magnifying glasses to inspect relationships.)
  • A highly abstract Reference Model and leaving all details to archetypes and codes. Why not in the extreme a Terminology that is capable to provide one code that represents the full works of Shakespeare.
    (Remember the first EHR standard that CEN/tc251 produced in the 1996)

When communities create any consensus it will work fine. Work fine for that community.

Or we come to a solution based on a pragmatic, logical, grounds:
Orthogonal layers and models in the semantic stack (RM, AOM, Archetypes/Templates, Codes, Ontologies)

This means that the scope of the layers are:

  • the RM: any Document structure, documenting/archiving these components (generic)
  • the OAM: production of constraints on the RM, meta-data about the archetype/template, exchange format (generic)
  • Archetypes/Templates: the Semantics - all facilities to safely interpret data (clinical and non-clinical semantics)
  • Coding system: provide codes and meaning like any dictionary (clinical and non-clinical)
  • Ontology: expression of Knowledge helping to define all codes/meanings (words) in the dictionary/coding system (clinical and non-clinical)

Each layer its own function.
No overlap of features between the RM and the Archetypes/Templates
No overlap of features between Structures (archetypes/templates) and SNOMED with its pre- and post co-ordination. The 'boundary problem’.
Overlaps always create problems.

All layers intersect, but will not overlap.
They intersect at the Archetype/Template layer.

Gerard Freriks
+31 620347088
gfrer@luna.nl

37

The point is that you don’t have to choose if you use generic kernel.

that’s also easy to do with reference models. There are many reference models right here, to plug into a kernel.

Ah, I did not know about this. I am very pleased to see it. It fits in the kernel-design philosophy I favor.

Thanks for the good work.

I found, that there are still some basic rules to which a Reference Model must apply. One of the basic structural ideas of the kernel is that it must be patient/EHR (say Subject)) centric.
Honouring this basic idea avoids having to write Reference Model-specific base structure code.

You can use multiple in archetypes-based reference models to validate and store and query data. You can allow certain parts of an healthcare organization, without any technical provision, to implement new ideas about medical data structures, maybe necessary for specific treatment.

sure, but like I said, this is just the same problem moved up one level. At some point, you still have to write classes with the semantics of things like Observation or Composition or whatever. Otherwise you can’t get the data on the screen, or compute with it in any meaningful way.

I think this can be solved with templates and information which can be in the archetype-meta-data. Don’t you agree? What am I missing?

Bert

38

What is to stop you using them? I have 5 reference models loaded into the ADL Workbench right now. Building a kernel to use them wouldn't be hard.

This is about what I advocate, multiple, interchangeable, simultaneously usable Reference Models.
I realized it by having multiple XMLSchema's in the kernel. Archetypes can be checked against them.

After this discussion, I think, now, it is the best way to go.

Thanks for your comments.

Bert

39

I agree Hugh, thanks for your comments.
My answer to Thomas, this morning, can as well be applied to your message.

Bert

40

example: is inside an openEHR OBSERVATION, and most implementations use full Java/C#/other implementations of these classes. That enables you to do things like handle openEHR OBSERVATION data representing time series from a device natively, including varying periodicity, varying sample widths, and varying math functions (max, min, ave etc). This makes it very easy for an implementer to get time-based data from an EHR and populate a screen graph widget. Without any of this built in, e.g. as in 13606, CDA, or other models, you have no guarantee that this kind of data (very common you will appreciate) is even represented in a standard way, nor do you have any classes to process it with. You have to assume that each CDA or 13606 data source has its own representation of such data, and build N implementations to deal with it. For openEHR implementers, openEHR is the target data, so we convert data into openEHR, which is a higher-fidelity format, and the problems go away. You could potentially convert them into a sort of standardised 13606, representing the same thing but then you’d still have to build your own classes to implement time-based data rather than re-use the standard classes everyone else uses. I don’t see the point. Especially as openEHR has AQL. Now, there are things that are not actually in openEHR, that you might want. So you can take the ‘reference archetype’ approach to that, and build local classes. But you might as well still use openEHR as 13606 or CDA as the basis, since you will get more for free - if you make your local native format something completely custom, then there is no community or software you can use - you have to build everything yourself. - thomas