I have a FHIR Bundle with requisition report that needs to go to multiple Practitioners. How would i represent this, would it be via references in a MessageHeader or...?
In the MessageHeader itself, we're a bit unclear on the meaning of multiple destinations. It might be for fan-out routing where the message is pushed to an initial recipient, which then sends to multiple places. Alternatively, it might tell the destination who else received the message (though at the 'routing' level, this is generally not useful information, so I'd presume only the first is intended).
The more useful level (the level surfaced at a business level and retained after delivery) for a cc is on the DiagnosticReport itself. Surprisingly, there's no standard element or extension for defining that. You could certainly define your own, but it might be worth submitting a change request and soliciting a standard extension for that purpose - to indicate who all intended recipients of the report are.
Related
I have been having some difficulties differenciation the two recently. More specificly I have browsed stackoverflow and there is a statement that Events can be named in two different ways:
with "ing" or with past tense "ed". This can be seen here Events - naming convention and style
https://learn.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-type-members
At the same time the CQRS states that names need to be in past tense and then following their guidelines the events named above with "ing" form would be commands. This gets me a bit confused? Do events mean different things in depending on the architectural context and movement. Is there a unified view on what an event and command is ?
CQRS you've been reading only had past-tense event names likely because they didn't consider pre-events. A command commands something to happen, and as such is typically formed in imperative ("click!", "fire!", "tickle!"). It makes no sense for a command to be a gerund ("clicking! clicking faster, you! or I fires you!") As it precipitates an action, it will likely trigger one or more notifications (=events) that something of note is about to happen, and afterwards that something of note did happened.
-ing events (e.g. ("Clicking") happen before the event is handled, e.g. in case someone wants to stop it. Sometimes, they are called "before" events (e.g. "BeforeClick"), or "will" events ("WillClick").
-ed events (e.g. "Clicked") happen after the event is handled, e.g. in order to affect dependents. Sometimes, they are called "after" events (e.g. "AfterClick") or "did" events ("DidClick").
Which specific scheme you follow does not really matter, as long as you (and your team, and your potential partners) are consistent about it. Since CQRS (under that name) is largely a Microsoft thing, follow what Microsoft says. Should you code for Mac, the concepts are similar - but you'd do well to go with the Apple guidelines instead.
Is there a unified view on what an event and command is ?
Unified? No, probably not. But if you want an authoritative definition, Gregor Hohpe's Enterprise Integration Patterns is a good place to start.
Command Message
Event Message
Within the context of CQRS, you should consider Greg Young's opinion to be authoritative. He is quite clear that command messages should use imperative spellings, where events use spellings of changes that completed in the past.
Names of Commands and Events should be understood to be spelling conventions -- much in the same way that the spellings of URI, or variable names, are conventions. It doesn't matter at all for correctness, and the computer is for the most part not looking at the spelling (for example, we route messages based on the message name, not by looking at the verb tense).
Events describe a change to the state of a model; all events are ModelChanged. However, we prefer to use domain specific spellings for the type of the event, so that they can be more easily discriminated: MouseClicked, ConnectionClosed, FundsTransfered, and so on.
Use of the present progressive tense spelling for an event name is weird, in so far as the message is a description of the domain model at the point of a transaction, where the present tense semantically extends past that temporal point. More loosely, present progressive describes a current state, rather than a past change of state.
That said, finding a good past tense spelling for pre-events can be hard, and ultimately it is just a spelling convention; the work required to find an accurate spelling that is consistent with the past tense convention may not pay for itself compared to taking a natural but incorrect verb tense.
Events in an event store (event sourcing) are most often persisted in a serialized format with versions to represent a changed in the model or schema for an event type. I haven't been able to find good documentation showing the actual model or schema for an actual event (often data table in event store schema if using a RDBMS) but understand that ideally it should be generic.
What are the most basic fields/properties that should exist in an event?
I've contemplated using json-api as a specification for my events but perhaps that's too "heavy". The benefits I see are flexibility and maturity.
Am I heading down the "wrong path"?
Any well defined examples would be greatly appreciated.
I've contemplated using json-api as a specification for my events but perhaps that's too "heavy". The benefits I see are flexibility and maturity.
Am I heading down the "wrong path"?
Don't overlook forward and backward compatibility.
You should plan to review Greg Young's book on event versioning; it doesn't directly answer your question, but it does cover a lot about the basics of interpreting an event.
Short answer: pretty much everything is optional, because you need to be able to change it later.
You should also review Hohpe's Enterprise Integration Patterns, in particular his work on messaging, which details a lot of cases you may care about.
de Graauw's Nobody Needs Reliable Messaging helped me to understan an important point.
To summarize: if reliability is important on the business level, do it on the business level.
So while there are some interesting bits of meta data tracking that you may want to do, the domain model is really only going to look at the data; and that is going to tend to be specific to your domain.
You also have the fun that the representation of events that you use in the service that produces them may not match the representation that it shares with other services, and in particular may not be the same message that gets broadcast.
I worked through an exercise trying to figure out what the minimum amount of information necessary for a subscriber to look at an event to understand if it cares. My answers were an id (have I seen this specific event before?), a token that tells you the semantic meaning of the message (is that something I care about?), and a location (URI) to get a richer representation if it is something I care about.
But outside of the domain -- for example, when you are looking at the system as a whole trying to figure out what is going on, having correlation identifiers and causation identifiers, time stamps, signatures of the source location, and so on stored in a consistent location in the meta data can be a big help.
Just modelling with basic types that map to Json to write as you would for an API can go a long way.
You can spend a lot of time generating overly complex models if you throw too much tooling at it - things like Apache Thrift and/or Protocol Buffers (or derived things) will provide all sorts of IDL mechanisms for you to generate incidental complexity with.
In .NET land and many other platforms, if you namespace the types you can do various projections from the types
Personally, I've used records and DUs in F# as a design and representation tool
you get intellisense, syntax hilighting, and types you can use from F# or C# for free
if someone wants to look, types.fs has all they need
RFC 2518 states:
The semantics of GET are unchanged when applied to a collection,
since GET is defined as, "retrieve whatever information (in the form
of an entity) is identified by the Request-URI" [RFC2068]. GET when
applied to a collection may return the contents of an "index.html"
resource, a human-readable view of the contents of the collection, or
something else altogether. Hence it is possible that the result of a
GET on a collection will bear no correlation to the membership of the
collection.
As a user of owncloud I often find myself suffering from the low performance of an initial sync of a folder containing lots of small files (See owncloud bugtracker for others reporting the same issue). After some investigation I came to the conclusion that the culprit is the underlying WebDAV implementation, which yields an index.html for a collection and thus forces the client to issue a GET request for each file. Since each GET causes a significant overhead (in the order of several hundreds of ms), the whole operation never uses the available bandwidth and is perceived as agonizingly slow.
So what is the reason that widely used WebDAV implementations do not allow a client to download a whole folder at a time? The specification does not explicitly forbid it. Surely this would increase performance, so I guess there must be some technical reason to this limitation.
The specification does not explicitly forbid it.
It does not forbid it, but it does not even remotely suggests that it's a something that the implementations should do. All the examples given are about retrieving a list or index of contents, not the contents itself.
Moreover, even if the server implementation chooses to support retrieving contents of a collection, there's no specification for format of that (how to package individual files into one download). So such implementation would be proprietary and your WebDAV client won't support it anyway.
Currently (02-12-2013), in the practitioner resource 0..1 names can be associated to a practitioner. In contrast, 0..* names can be associated to a patient. This allows specifying a person's maiden name for example. Why is there this difference?
In the project I'm working on, we're exporting existing data about practitioners from our database using FHIR messages. In the database, all persons are stored in the same way. Since it is possible to store a person's maiden name (which is also done for practitioners in our data), we have to build the name part in a practitioner message differently from the name part in a patient's message. Also, when parsing a practitioner message, we'll need different code to extract the name of a patient and of a practitioner.
Therefore, I believe that there are two disadvantages of having different generic attributes of persons of different kinds:
It prevents us from sending the complete name information of a practitioner without resorting to extensions.
It complicates the code for building and parsing FHIR messages, which also makes the code less maintainable.
I understand that in most cases it's not very important to be able to send the maiden name of a practitioner, but it does add extra complexity for the implementation. Furthermore, I don't see what problems setting the cardinality to 0..* could cause. If someone only wants to send a single name, then that's still possible.
Similarly, the restriction of only allowing 0..1 addresses for a practitioner (as also discussed here) also seems like an unnecessary restriction.
Managing cardinality is a tricky issue. If the resource can have multiple names, then everyone dealing with this has to deal with the possibility of multiple names. The relevant committee believes that having multiple names is an unusual practice for practitioner records (that's certainly my experience) but a common one for patient.
Perhaps you'd like to explain your full use case so it can be considered by the committee? On the other hand, you can use an extension:
<Practitioner>
<extension url="http://myurl.com/fhir/profiles/extensions#maiden">
<valueHumanName>
<!-- details for human name -->
</valueHumanName>
</extension>
</Practitioner>
Therefore, I believe that there are two disadvantages of having
different generic attributes of persons of different kinds:
When designing Patient, Pracitioner and RelatedPerson, we have tried several different solutions:
having Person resource, separate from Patient/Pracitioner. This proved to be burdensome since many systems (unlike yours!) don't capture patient and person separately, and when looking at REST useage patterns it turned out they were always needed togehter, resulting in unneccessary burden on client and server
Having a special Demographics datatype which contained all shared attributes. This met resistance since it meant having attributes on Practitioner that did not make sense, e.g. marital status and deceasedDate. This run against our intent to keep the Resources focused to their scope and the number of attributes per resource manageable.
This is how we ended up where we are now: more or less "duplicating" the attributes (when applicable) across those three resources.
Similarly, the restriction of only allowing 0..1 addresses for a practitioner (as also >discussed here) also seems like an unnecessary restriction.
The Practitioner resource represents a person employed by an organization to provide care. We assumed that for one such engagement, there is one "official" (post) address for that person. The practitioner may however perform services at multiple locations (each of which can have an address).
i am thinking of making a website..
bt how can i make sure that when a user who is asking some question is nt using any abusive language or the message is totally subject oriented..
i m nt talking about spams..i know about captcha and all..
what i am asking is how can i keep an eye on human activity[in this case the messages sent] and at the same time providing the user his complete privacy!
One word... manually.
They're on the web, they already don't have complete privacy.
Offer the community the means to police themselves, whether by explicitly appointing moderators (like most bulletin boards), allowing them to decide who they can and cannot see (like social media sites), or collaborative moderation (like here).
You can set up a system where comments/posts must be approved by a moderator before being allowed to be posted. I believe Wordpress can do this.
There are curse-word filtering libraries available in most languages, usually complete with the ability to customize the words that are filtered out.
In order to filter spam, there are things like bayesian spam filters which attempt to determine whether a message is spam based on keywords in the response. This really isn't something you would want to attempt to do yourself.
Another thing to look at is Markov Chains. They are designed to generate strings of seemingly valid text based on the probability that any given word is followed by any other particular word. Using a reverse process you can attempt to determine if a string of text is valid by checking whether the words used are following by other "on-topic" words.
This would be very difficult as well.
In order to keep the privacy of the users, you could use combinations of these three tests to create a threshold. That is, you will examine no messages unless they reach a high curse/spam/off-topic score. At that point, those messages will be manually checked to see if they are appropriate.
There currently is no way to have a 100% automated process that won't block valid messages and let invalid ones through.
how can i keep an eye on human activity
Your answer lies here. I don't quite understand what you're getting at about privacy though.