FHIR Chat · Objective FHIR

I have a class hierarchy that expresses FHIR in an object-oriented form. The classes in the model are based on commonalities between various resources, and arranged according to similar functional semantics. The class structure starts at DomainResource and eventually reaches the Resources. In between, there classes that contain common elements that occur in multiple resources. An example is a generic Request, which specializes to ServiceRequest, and then ReferralRequest and ProcedureRequest. The hierarchy also extends below the resources, describing additional classes that map to profiles. By creating child classes, you can extend FHIR in object-oriented fashion. The classes also smooth out some of the irregularities between resources, such as, where one class uses different name for the same semantics. So in the "parallel universe" of object-oriented classes, things are a bit more consistent. I also have the capability to exported the entire thing as FHIR profiles in DSTU2, STU3, and (very soon) R4 -- thus creating profiles and implementation guides. Objective FHIR, as I'm calling it, has also developed conversions from FHIR resources into the object-oriented form (in ES6) and back, so business logic can be executed on the object-oriented version of FHIR.
Basically this is just a trial balloon to see how many people find that idea interesting. Is this something useful to the FHIR community?

Georg Fette (May 06 2019 at 06:57):

Sounds very useful, or at least I have a use for it. I also had to write something that does parts of that and would love to replace my own implementation by something more sophisticated. Did you use a specific programming language or did you manage to make the approach programming language agnostic ? Will it be publicly available ?

Grahame Grieve (May 06 2019 at 10:39):

I've been intending to generate the patterns into HAPI at some stage. Howe much do you follow the patterns?

Grahame Grieve (May 06 2019 at 10:40):

as for profiles as classes - that's problematic because profiles are patterns of use, and not exclusive. A single resource may conform to multiple different patterns. I've been intending to generate facades for the profiles

Grahame Grieve (May 06 2019 at 10:40):

a few of us discussed what you're doing last night. Can you comment on how consistency has progressed over FHIR releases?

Grahame Grieve (May 06 2019 at 10:41):

and the things you smoothed over - do you want to create tasks for committees to consider making changes for them?

Lloyd McKenzie (May 06 2019 at 11:23):

As a secondary view this could be useful, but the serialization couldn't be driven by it because it messes with the sort order. Also, it wouldn't work for projects to continue extending. The schemas need to be fixed and universal.

Lloyd McKenzie (May 06 2019 at 12:37):

We'regoing to spend some time talking about this today, Q4 - Salon Drummond East

Nick Radov (May 06 2019 at 13:26):

I built something conceptually similar to that years ago for the HL7 V3 RIM. But FHIR has moved away from the OO inheritance model. Any commonalities between resource types are supposed to be represented by Design Patterns.
http://www.hl7.org/fhir/documentation.html
So a FHIR OO model would generally have only a single inheritance layer with all resource type classes inheriting from a an abstract "Resource" superclass. And then interfaces for each of the four design patterns, which would be implemented by each of the resource type classes which follow those patterns.

Grahame Grieve (May 06 2019 at 13:29):

that's how I've been thinking about it

Grahame Grieve (May 06 2019 at 13:29):

but note that I do generate one additional super type in the HAPI classes - a Metadata resource

Peter Jordan (May 06 2019 at 13:56):

The C# Reference Library has an abstract base Resource Class from which all Resource Type classes inherit and this includes a Meta object property which is an instance of a meta (data) class.