Stream: openehr
Topic: Working together
Grahame Grieve (Mar 31 2016 at 06:04):
it seems to me that there's seveal different issues to sort out here. The first is implementers vs clinicians. That's a false dichotomy, but one openEHR pushes as much as FHIR does. ("it's just how it works in our community - clinical models get done by MDs, RNs and so on. IT people only get involved at the template level"). Clinicians can be implementers too. We focus on implementers for 2 rasons:
- they are held to acheive actual outcomes (the journey is not the outcome. We all have too many people who think otherwise around us)
- implementers understand the constraints on their actions due to past decisions, practical obligations etc
too many models I've seen, a bunch of clinicians sit down ad brainstorm about what 'should' happen without considering *why it doesn't already happen* - often there's good reasons. That's why Ian's note about the involvement of Informaticians from the beginning of the process is critical - and rarely reflected in openEHR pronouncements on the subject.
There's certainly things that we have in FHIR because of this. No rational clinical model would say 'let's do it this way', but the fact is, already everybody does it that way, and we could only change that by ignoring legacy data. in regard to the 'implementer focus' we could achieve most of it by focusing on legacy data. I've participated in archetype design, but it's usually just me saying 'hang on, there's a reason why we do it this way' - but there's other informaticians who do that - *if the focus is interoperability* (it isn't always). But focusing on legacy data alone wouldn't deal with the first part, the practical part. And as you all know, that was a critical problem at HL7 when we started
So I think that we should be able to come up with some joint statement around this part - what our approaches are, and how they differ a little
Grahame Grieve (Mar 31 2016 at 06:12):
The next thing I wanted to pick up on was that there's widely variant notions of what openEHR is doing, and what standards should do, here.
and this is a new problem for HL7. No one ever came to HL7 and said, hey, we love v2 so much we want you to help us use it for something entirely different to the standard. So we have no institutional experience of this.
in fact, it's worse, because people did that privately, and then thought they had a nice closed community, like Tom describes (quaint kind of country estate...), but it turned out, no, they weren't. And so they were misusing v2, and people didn't blame them, no, they blamed HL7. That was an enormously strong message from the implementer community.
So all of HL7's institutional experience screams out that what Tom is talking about is a MISTAKE for HL7 itself
that doesn't make it one, actually, but I think that is critical background to this whole subject. And there's a degree of truth in it; one way to externalise the costs of data sharing is to make private agreemnts; works really well for the ones making the agrements, screws the rest of the world over.
This perceptional issue underlies much of this thread. And I believe that openEHR has to take the concern most seriously if we're going to work together.
Grahame Grieve (Mar 31 2016 at 06:14):
and possibly, openEHR might have something to learn generally from that. Tom claimed that "in openEHR isn't 11 ways to describe X, there is just one, but if national programmes want something different, they can define it" - only, I've never run into anyone implementing the 'just 1' - they're always implementing some national variant of it as far as I can tell
Grahame Grieve (Mar 31 2016 at 06:14):
so I think of openEHR as a system for producing swarms of models
Grahame Grieve (Mar 31 2016 at 06:19):
one other thing I want to say: we've been discussing with CIMI whether they want to just propose some of their models as FHIR resources directly. They can do that; they'd be subject to the same governance as the rest of the resources. But as an HL7 committee, they can't ignore the existing agreements and just make their own up. But they'll have that rule whatever they do about that
Grahame Grieve (Mar 31 2016 at 06:19):
that doesn't mean that the same rules apply to other participants that are not HL7 members
Erik Sundvall (Mar 31 2016 at 07:01):
Grahame, regarding "swarms of models" I and several others think openEHR could be more outspoken (dictatorial?) regarding the use of openEHR for making national silos without any strong connection to the international modeling.
It's a process problem more than a technical/spec problem, not too different from the "misusing v2" scenario you described. So please make this differentiation when talking about openEHR fragmentation, it's no different than national govermental programmes abusing HL7 techniques. They risk destroying FHIR too (everything that is not locked down) with isolationistic/nationalistic practicies. We need to educate them, describe and fight this problem together in a general way - not by pointing to abuses of "the other" approach.
Locking down optionality at a technical level the FHIR way is one way of attacking the problem, but it has other drawbacks regarding agility etc. It should not be presented as the only way to fight fragmentation.
What you are missing in your openEHR-world-analysis is the Norwegian way of doing openEHR modeling - where the national coordination is primarily done by user-organisations (healthcare providers/regions) and vendors working together. It is also tightly coupled to international review rounds etc. (AU and GB is not the world.) One space to Watch is Brazil - I am not yet sure if they are most similar to the AU/GB govt approach or the Norwegian way of doing things.
Erik Sundvall (Mar 31 2016 at 07:04):
In another conversation @Ian McNicoll mentioned that national programmes sometimes deliberately did their "own thing", using openEHR tools/methods because they "didn't want to favor any specific vendor" (or something along those lines). Perhaps you can tell us more here Ian?
Grahame Grieve (Mar 31 2016 at 07:47):
so I think that openEHR is missing a governance layer here - I always have. There should be base models that everyone has to abide by. Then you put whatever can be agreed internationally in the base models, and you get more interoperability out of the box. However I recognise that 'interoperability out of the box' isn't the goal. Sometimes
Grahame Grieve (Mar 31 2016 at 07:48):
as an example of this, openEHR could define an 'observation' archetype. Then they could map that to the FHIR observation. Then they could rework existing archetypes to be constraints on the openEHR archetype - and voila! - all the archetypes are now FHIR observations, and can be interoperated with everyone directly
Grahame Grieve (Mar 31 2016 at 07:49):
part of my point here is that this discussion is *not about modelling formalisms*. It's about community size, and whether a particualr community needs to buy into everything in order to by into part of it
Grahame Grieve (Mar 31 2016 at 07:58):
and who should bare the cost of interoperability
Grahame Grieve (Mar 31 2016 at 07:58):
which gets back to Andy's point. There's no single answer. But if you've seen one v2 interface... you've seen one v2 interface.
Grahame Grieve (Mar 31 2016 at 07:59):
one of the fears people express to us all the time is that this will turn out to be true for fhir as well
Erik Sundvall (Mar 31 2016 at 09:52):
Regarding who takes the cost for interoperability/intraoperability: a lot of it usually lands on us, the healthcare providers when we need to connect our real systems for real use...
Sometimes some vendors can buffer part of the cost (but we get to pay it via the price of their product anyway). Sometimes the cost is taken at some national level using national tax money or money pooled from regions with shared interests. In the case of well-workinig national collaborations and somewhat aligned source systems we can share the costs (by reusing mappings/models developed jointly). Sometimes top-down national projects instead mostly add to the burden/cost by adding new nationally invented ways to model.
And as usual, the more different we (helathcare providers) insist on being inside the systems, the higher the cost of interoperability/intraoperability - that's why I like clinically acceptable and understandable ways/methods of creating growing consensus on how to document similar things... And I have not seen many better and scalable but still agile ways to do that than the Norwegian+international archetyping efforts (working communities, processes, tools and active governance).
Erik Sundvall (Mar 31 2016 at 09:58):
Grahame, regarding "Observation". What things/fields would you like to add or constrain in such a reference master Observation-archetype? What is missing in the openEHR RM for Observations? Is the RM too powerful/open? Please help me understand what you are looking for.
Grahame Grieve (Mar 31 2016 at 10:07):
The FHIR observation lays down some expectations about how things are categorised and structured. So there's some practical things. But mostly, I didn't really have in mind issues with the actual content so much as a structural place to assert the structural similarities. But I did say it would say more than the rm didn't I? Well, I think I should do some research before I shoot my mouth off based on bad memories
Erik Sundvall (Mar 31 2016 at 14:08):
Just testing a thought here...
Many EHR systems of today have some parts/modules that are more hard-coded in software (medication modules, lab modules etc) and other parts that are almost completely customer configured (e.g. documentation modules with a lot of configurable forms, often including narrative parts too). This distinction is of course a continuum, as usual...
Could we see a situation where caregivers and/or national programmes are encouraged to focus on
1. interoperability solutions like standard FHIR resources (with some exensions) for things that are usually hardcoded in systems
2. and look for intraoperability-focused processes/methods like openEHR (on FHIR?) for the things that are usually user-configurable, diverse and fast-changing,
3. and wisely evaluate options for the things that land inbetween the categories...
Reactions?
Lloyd McKenzie (Mar 31 2016 at 14:12):
Possibly. FHIR profiles and questionnaires can be used to support #2 as well, but there isn't any particular set of processes defined within FHIR around how consensus is formed around what those things look like.
Thomas Beale (Apr 01 2016 at 17:26):
openEHR's approach is complete separation of payload from delivery mechanism. Well nearly. The RM builds in context attributes, audit details, versioning and other needed semantics for an EHR. But I am not convinced what implementers are going to add to a clinical modelling effort on say Apgar score. If anything, implementers might look at the Reference Model, which was designed to minimise implementer errror. @Grahame Grieve can you give an example of how developers are going to help in the design of a clinical archetype?
Peter Jordan (Apr 01 2016 at 19:31):
Interestingly, one of the key points from a recent study of the Norwegian implementation of openEHR is that "The separation of clinical and technical concerns seemed to be rather aspirational as both designing the technical system and modelling the domain required technical and clinical competence."
Bente Christensena & Gunnar Ellingsen, Evaluating Model-Driven Development for large-scale EHRs through the openEHR approach (15 Feb 2016).
Lloyd McKenzie (Apr 01 2016 at 20:27):
@Thomas Beale Grahame's off surfing for a week, so he may not get to this for a bit. I'll take my stab. Blood pressure is probably a good starting point. The openEHR model contains 10 main elements (systolic, diastolic, mean, exertion, body position, etc.) Implementers (in most environments, not necessarily all) would indicate that having 10 data elements in the UI to capture blood pressure is unreasonable. Certainly most of those notions would be relegated into the "extension" or "optional" space when profiling. It's not that they're never relevant, it's that within the scope of most practice, that information is either not relevant or implicit. Implementers will add considerations around screen real estate, data entry time, navigability, support of legacy information, consistency with other similar data (allowing re-use of user interface components), ability to search/sort/filter, etc. All of which is vital to having data actually captured and displayed in real systems.
Lloyd McKenzie (Apr 01 2016 at 20:27):
@Peter Jordan Agree you definitely need both throughout. Systems that don't reflect both clinical need and reality and software development need and reality either won't get implemented or won't function well enough to achieve the desired benefits.
David Hay (Apr 02 2016 at 00:07):
and of course, if you did want to adopt the 'maximal data set' approach in FHIR, you could create a profile with all 10 elements in it as extensions, then have other profiles that constrain the 'uber profile' (not saying I believe it to be a good idea, but it is feasible)...
Thomas Beale (Apr 02 2016 at 12:38):
@Lloyd McKenzie there is a basic misunderstanding here. The BP (or any) archetype includes _possible_ data points / groups. The elements are nearly all optional. The choice of what actual elements are needed in some particular circumstance, form, communication etc, is defined in an openEHR template, which includes as few or many of the elements as it wants from one or more archetypes, and sets them optional, mandatory as needed. It 'removes' the others by constraining 'occurrences' to {0}.
So the archetypes are a _library_ of data points/groups/value sets _independent_ of use context. It is the templates that are the fundamental unit of data set definition in openEHR. Implementers do build templates - based on product, or context, form etc.
openEHR templates (and specialised archetypes for that matter) provide what you think of as 'profiling'.
So - I still have to ask - what would implementers have to do with the process of defining clinical archetypes?
Ian McNicoll (Apr 02 2016 at 18:16):
@Thomas Beale "So - I still have to ask - what would implementers have to do with the process of defining clinical archetypes?" In the context of 'implementers' meaning those people who have implemented systems originally based on clinical requirements, I am very keen to have implementers involved in clinical content modelling. Not alone, and not to the exclusion of other clinical informaticians or clinicians with domain knowledge but neverthelesss a very important source of expertise.
@Lloyd McKenzie - just to reinforce Tom's point above. There is no way that any implementation is going to have all of the blood pressure archetype data ppoint is the Ui or even the allowable end-use dataset (your profiles/our templates). The point of the maximal dataset is just to allow the development of a rich, shared understanding of the varied requirements around a given topic, particularly where the intent is to support native system information models. It is an aspiration not a strict requirement, and it is certainly not reflected in actual system use. In fact, I think if you look at the key FHIR resources and equivalent archetypes meds, allergies, conditions etc, the difference in 'maximality' is not that evident. There will be differences in observations as we are trying to capture knowledge about each archetype needed for in-system use, not just that subset likely to be of interest for data exchange, but I suspect that over time, the exchange requirement will start to meet the in-system requirement e.g. a specialist departmental module interacting with a 3rd-party app and needing fairly granular, specialist aspects of the model not required for generci exchange.
David Hay (Apr 02 2016 at 18:44):
What would be good to understand is how difficult technically it would be to create profiles that represent the 'maximal dataset' of an archetype. For example, casting the BloodPressure archetype as a StructureDefinition resource. How well aligned are the datatypes for example...
Ian McNicoll (Apr 02 2016 at 19:28):
@Erik Sundvall Paradoxically this has largely occurred where openEHR is being used to develop clinical content to underpin HL7 CDA messages. I think part of the problem has been that HL7v3/CDA was late to develop a strong templating development/publication mechanism to support international archetype/resource scope artefacts and tended to rely more heavily on specific national message- constraints with a higher dependency on terminology such as SNOMED CT.
In those respects, FHIR and openEHR are much, much better aligned. The datatypes are closer, the scope of artefacts is closer and the approach to terminology use/dependency is very similar. There are some areas of mismatch, particularly around Observations but I do not believe these are road-blocks to joint development of clinical content, even if it will make automation more tricky in the short term.
Lloyd McKenzie (Apr 02 2016 at 21:04):
@Thomas Beale If the archetypes represent theoretical constructs of information that could potentially exist with no expectation that most or even any system would actually use all or even most of that information, then perhaps implementers wouldn't add much to the conversation. In FHIR's case, we try hard to never design at that level. Our focus is on the data that we know is going to be used. We may define some of the other bits as extensions too - for those who need them, but it means that an implementer can look at our spec and know roughly what's expected vs. edge case in most environments without having to do any site specific profiling (though profiling is still needed to get to really tight requirements). The essential difference is that openEHR's initial designs are focused on "completeness", potentially independent of implementation practice. FHIR's designs are focused on implementation practice, potentially independent of "completeness". In openEHR, the implementation practice comes from later constraint. In FHIR, completeness comes from later extension. In the end, we can both express the same things, but we come at it from different directions.
Ian McNicoll (Apr 02 2016 at 21:43):
@Lloyd McKenzie "The essential difference is that openEHR's initial designs are focused on "completeness", potentially independent of implementation practice. " I don't recognise that as the way that openEHR clinical modelling works at all! Where there is some sort of prior implementation, whether other formalisms such as v2,v3 or FHIR, or other national data exchange standards, system screenshots/ paper documentation, we would always, at the very least use this as our foundation, and an absolutely key requirement.
I think too the suggestion that we are 'focussed on completeness' is something of a misreading of both the philosophy and the reality of model development. We certainly make an effort to understand a broad sense of clinical requirements and good practice, and are comfortable to allow concepts and variance that are expressed by our reviewers (though that is not absolute either), but completeness is not achievable either in fact or in any sensible timescale. Most of the difficult and time-consuming issues that we have to wrangle with are mostly presented to us by our vendors/implementers, since these represent the challenges faced by them as in-system requirements. This is, of course, at-odds with the FHIR philosophy /requirement, which is limited for now to limited interfacing between systems, but as the scope and depth of that interfacing grows (or indeed attempts to use in-system), I believe FHIR will face the same issues, forcing more and more competing extensions to be created. If nothing else, the openEHR maximal dataset approach tries to reduce the number of competing secondary artefacts by making the primary artefact better fit-for-purpose for a wider group of consumers. So we hope to reduce the number of extensions, whilst recognising (as per FHIR) that further profiling will be required to turn these primary artefacts into locally useable profiled/templated models.
Interesting discussion.
Lloyd McKenzie (Apr 02 2016 at 21:52):
Hi @Ian McNicoll, it could just be a question of impression. I'm not meaning "completeness" in an absolute sense, but I do have an impression from openEHR models that there's more sophistication/capability present in may of them than would be present with the FHIR approach.
Ian McNicoll (Apr 02 2016 at 22:05):
@Lloyd McKenzie I agree, particularly in the way we do Observations, but while there is in openEHR an attempt to understand and document the breadth of possible approaches, that broader content is just as much a reflection of in-system requirements, which are not currently a priority for interface requirements. I did suggest elsewhere that we might act a little like the 'canary in the coal mine' in highlighting what comes next, or in helping guide the content of 'core Profiles'
Thomas Beale (Apr 03 2016 at 08:17):
All - I think this idea that only FHIR is implementation oriented and that openEHR is somehow 'theoretical' and not implmentation-oriented is not helpful. They're both implementation oriented - we are all doing our respective things in order to implement solutions that work, and we all do that. We just do it differently.
The openEHR approach is to create a library of data points / data groups that are independent of particular use - these are the archetypes. This is the only rational thing to do: there is no point modelling all the blood pressure data points, or any of the other 10,000 data points any more than once. Without a library approach, any effort is doomed to repeating definitions of what should be re-usable clinical entities. Now, in openEHR, it is primarily clinical people who write the archetypes - it's their subject matter after all. Implementation type people may also contribute, but it's not on the basis of a particular system (unless the archetypes being developed are specifically for that solution); it's more to provide input on 'what current systems do'.
The next thing that is needed in any modelling ecosystem is a way of assembling domain data-points and data-groups into context-specific data sets - it could be the data for a form, a particular message, a document etc. In openEHR, this is called a Template, and this is what is deployed - all openEHR systems are built with templates, which in turn contain the relevant bits of various archetypes. Templates have an important properly - they preserve the paths of archetypes elements they use. The people who build these templates tend to be more implementation oriented, and also local to the solution being built (but you can still build a standard template for a country, e.g. a discharge summary).
The next step is to create and persist data. Data in openEHR correspond to the templates, which means that they actually all correspond to the archetype structures, including the archetype paths. Doing this practically is where template-generated downstream artefacts come into play - we generate all kinds of things from the templates - XSDs, facades, REST URIs and so on. These are what get used by application developers.
Now we get to querying: here we use a simple language (AQL) based on archetype paths within a SQL-like statement structure, also the '//' XML operator, and this is all that is needed to enable queries written straight from archetypes to work over all that templated data. AQL querying is the backbone of operational openEHR systems - it sits behind most forms. The queries are all reusable, due to only being dependent on the archetypes.
What's really happening in the above is that there are different points in the development of any given clinical model content at which different types of professional become involved, where it makes sense.
I hope this clarifies.
Ian McNicoll (Apr 03 2016 at 08:31):
@Thomas Beale Thanks - good summary.
Thomas Beale (Apr 03 2016 at 10:41):
One p.s.: all of this, and any other standards-like effort (FHIR included) is of course wrapped up in the sociological and political realities both internal to SDOs/SROs and in the wider world. These other actors may try to impose their own 'top-down' visions or other ways of working which might not always fit nicely with the vision of the standards developers. Result: developing real practical social networks that do have the desired outcomes can be a real challenge. As Ian always says, nearly all the real 'problems' are people-related, not technological. Nevertheless key aspects of HL7's and openEHR's (and all other ecosystems) internal vision does involve social aspects like crowd-sourced modelling and agile implementation, and these are quite tricky to get right.
In the end I would make a plea for all major ecosystem/SDO/SRO groups to at least try to understand clearly what the intentional basis of the other ecosystems is, and distinguish that from unintended consequences due to sometimes inappropriate or misguided uses in the real world. When we do that, we can have better conversations both on the technical level and on how to better take account of sociological challenges.
Koray Atalag (Apr 03 2016 at 12:33):
Hi David, I'd be more than happy to sit with you and have a stab at the Blood Pressure example
Thomas Beale (Apr 03 2016 at 12:59):
@David Hay the data types are not an issue; if we pursue the 'making FHIR work for everybody' programme, it is assumed that the FHIR data types, identifiers, demographic entities and probably some other elements I can't think of right now are being used, so conversion would be performed from openEHR or other model system X into profiles based on openEHR-on-FHIR resources, but with all those generic things being converted. If we discover that some openEHR data type can't be converted we would raise an issue in the normal way and in some cases the FHIR infrastructure might need some adjustment.
I would not expect much of that, since Grahame took the trouble to look at the openEHR data types during early FHIR development. The area I think that will be 'interesting' will be as usual, representation of coded terms and value sets. Generally openEHR just tries to follow mainstream good practice here.
For reference: a partially completed FHIR/openEHR datatypes analysis: https://openehr.atlassian.net/wiki/display/stds/FHIR+-+openEHR+Data+Types+cross-analysis
Erik Sundvall (Apr 03 2016 at 15:32):
(deleted)
Erik Sundvall (Apr 04 2016 at 16:03):
@Peter Jordan regarding the paper by Christensen et al. It has been discussed on the openEHR mailing lists. One of my favourites from that thread is the reply by Seref Arikan, available at https://www.mail-archive.com/openehr-clinical@lists.openehr.org/msg03940.html
René Spronk (Apr 04 2016 at 16:12):
to bad the paper itself is behind a paywall..
Erik Sundvall (Apr 04 2016 at 19:03):
@René Spronk you already have access to the things that most (non-open-access) publishers have agreed is the most important core dataset. It is at the resource http://www.ijmijournal.com/article/S1386-5056(16)30024-7/abstract - from there you can find a human readable abstract, title, ID etc. If you access http://www.ijmijournal.com/article/S1386-5056(16)30024-7/references you even have full description of references and can do some interesting statistical analysis etc... :-)
Do you need access to the whole paper? Something like open access to to the internal datastructure and content of the publication? That would require the authors to be a bit altruistic (or rather their financing sources to demand an open approach) and invest a bit in openness up front instead of trusting the publishing house to do things for them (making somebody else pay). An open knowledge sharing would force the publisher to change their business model, and that would only happen if the authors or a big enough part of their support system demand such a change. :-)
Erik Sundvall (Apr 04 2016 at 19:25):
Just kidding a bit to make a point of course. The point is that a change toward openness and a willingnes to pay for openness up front has been going on for long time in scientific publication. (Not many think that good quality publishing will be a free process so the authors now pay instead of the readers. Some enhusiast completely "free" publishing channels will of course always be available but that won't kill the ones requiring fees of authors.)
A great text about the issues is: http://www.nytimes.com/2016/03/13/opinion/sunday/should-all-research-papers-be-free.html
Medicine is hopefully a somewhat scientific endavour, so it should not be too far-fetched to see something similar regarding open EHR structure/content/knowledge. But most likely it will be like in scientific publication and not change much before the people financing/buying the systems understand the benefits of openness. (Some regions/segments/customers will go the open way earlier than others.) Until then it is great to also have some standardized simple way to access "abstracs" and other bits and pieces of EHR content, so there is room for borh openEHR and the current FHIR approach. And access to important pieces is a lot better than no access or complicated access.
Erik Sundvall (Apr 04 2016 at 19:37):
Some scientific publishers/publications will likely stay "closed", some go all in for open access publishing, others take a hybrid approach and let the authors decide on business model on a per-paper-basis; if the authors pay it will be open access - if not, readers will hit the paywall (unless they are already subscribers).
In the EHR-world you see some hybrid and transitional approaches to things like openEHR.
Erik Sundvall (Apr 04 2016 at 20:03):
Perhaps the openEHR-on-FHIR approach (some HL7-acceptable version of Tom's "making FHIR work for everybody") is a hybrid that will make FHIR useful also for those that want the internal core of clinical systems to be (or become) open.
Koray Atalag (Apr 08 2016 at 00:45):
Rene (and all) the editor of the journal (IJMI) Jan Talmon made the article available to openEHR technical list - which is open. You can access the paper from: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/2016-March/009664.html
Koray Atalag (Apr 08 2016 at 00:51):
Is there appetite in FHIR community to tackle Tobacco Use or Tobacco Smoking Summary model? I have a new Masters student who's just starting to look at existing models and modelling approaches in this domain so I'd be grateful if you can point out to what is already out there and any plans to tackle this model. Many thanks
Lloyd McKenzie (Apr 08 2016 at 02:44):
The only work I'm aware of in that space is the U.S. Data Access Framework implementation guide. The relevant profile is here: http://hl7-fhir.github.io/daf/observation-daf-smokingstatus.html, though it's not terribly detailed.
Koray Atalag (Apr 08 2016 at 02:48):
Thanks Lloyd - can you let me know if the core FHIR team thinks this is one of the key clinical concepts that's worth looking at aligning with openEHR? It'd be good because we'll be looking at the modelling process and resulting models for every model that exists in this domain (e.g. CDC has well adopted definitions, probably all big vendors have their own schema for this, etc.)
Lloyd McKenzie (Apr 08 2016 at 03:23):
It's a profile, so it's not really a key concept for us. The key concept in FHIR is the resource, which in this case is Observation - which is a *very* key concept. But it probably corresponds to 20+ archetypes in OpenEHR - we use it for vital signs, lab results, scores and a bunch of other things.
Koray Atalag (Apr 08 2016 at 06:07):
From "data reuse" and "interoperability" points of view I believe this is such a fundamental information model in all walks of clinical medicine, research and policy making. Perhaps FHIR needs to come up with some levels of Profiles (e.g. those critical to get right such as the vital signs that Grahame made a call to action recently and non-critical - perhaps even more levels). My c cents
Lloyd McKenzie (Apr 08 2016 at 13:26):
It's possible we will do that at some point - quite likely building on the work already done in the US. However standardizing a panel like smoking history is a significant jump from simply standardizing how to capture certain physical measurements.
Last updated: Apr 12 2022 at 19:14 UTC
