"The strong point of FHIR (where its success comes from) is that every application can understand it. For this reason, I think that OpenAPI will suffice for the purpose."
Which is not actually true, since every FHIR resource needs to be profiled to be safely understood, often very heavily (see Observations). But I agree that FHIR does represent (for some use-cases) a more business-oriented API than openEHR which is deliberatly more low-level, However FHIR, in practice, is itself much more complex (especially once you add in all the extensions/ localisations/ terminology bindings and than say a locally crafted API like Ripple. The unique point of the openEHR API is that the receiving system (a CDR) does not have to pull apart the incoming data structures (or at least it does not require re-engineering for every new structure). This is harder for newbies to understand but reduces the overall engineering effort substantially especially for new data structures. So there is a place for lower-level API - openEHR service (or whatever, with varying content representations) Broad business API -FHIR (for openEHR based on common templates mapped to local FHIR profiles) - see https://github.com/Code4Health-Platform/openehr-care-connect-adaptor for an example. The templates are designed to be UK wide. Specific business API - e.g Ripple depending on your 'consumer' The native data is complex, you cannot dodge that if you want to deliver sophisticated health systems. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: [email protected] twitter: @ianmcnicoll Co-Chair, openEHR Foundation [email protected] Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On Tue, 17 Jul 2018 at 10:01, Bert Verhees <[email protected]> wrote: > On 16-07-18 16:59, Thomas Beale wrote: > > well whether it is 'so good' is in the eye of the beholder, but it is > 'good enough' for quite a lot of things, things for which we would once > have expected to be able to use XMI. Anyway, the BMM introduction > <https://www.openehr.org/releases/BASE/latest/docs/bmm/bmm.html#_introduction> > provides some information on why it is there. > > BMM does not serve the purpose of describing API's. It serves the > describing of software models. > > API's are communication-protocols. You can compare them with network > protocols. There can be structures in them, and there are, in JSON, also in > protobufs. > > But these structures do not serve the purpose of building an application > around it. They only serve to communicate data. The receiving party must be > able to recognize the structure, but the receiving side does not need to > know that a list of structures is of a generic type. It will find out when > reading the message that all the components of a list are from a specific > type (if it is interested). Maybe for the receiving side, the fact that a > specific list has generic data-items is not important, because in its own > universe this is different. The same counts for hierarchy/inheritance. The > receiving side does not need to know that a structure in message A is > inherited from a structure in message B. > > The receiving side probably will tear apart the structures and reorder the > data in its own structures. > > So any API design method which handles generics and inheritance > communicates a lot of useless information, unless the other side is exactly > the same machine, then they have a common center of the universe. However, > this should never be the purpose of an API, nor the purpose of a message. > > The strong point of FHIR (where its success comes from) is that every > application can understand it. For this reason, I think that OpenAPI will > suffice for the purpose. > > Bert > _______________________________________________ > openEHR-technical mailing list > [email protected] > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
